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ABSTRACT 

Software  maintenance  costs  in  Naval  Aviation  Operational 
Flight  Programs  (OFP)  are  very  high  and  are  projected  to 
climb  higher  in  the  future.  Maintenance  costs  are  high  due 
to  poor  initial  design,  limited  programmer  and  system 
resources,  poor  documentation,  the  conditions  under  which 
the  OFP  must  operate  and  the  difficulty  involved  in 
performing   meaningful     flight   software   tests.  The    primary 

factors  which  produce  the  stated  problems  with  aviation 
software  systems  are  discussed.  The  maintenance  phase  of 
the  software  lifecycle  modal  proposed  for  standard  applica- 
tion software  systems  is  contrasted  with  that  for  real  time, 
embedded,  aviation  software  systems.  A  limited  set  of  soft- 
ware tools  and  methodologies  which  are  currently  available 
and  would  greatly  aid  the  system  engineers  tasked  with  OFP 
maintenance      is    proposed.  These      tools   and      methodologies 

center  on  two  areas  of  flight  software  maintenance;  documen- 
tation and  testing.  The  thesis  concludes  with  recommenda- 
tions  for  future   aviation   flight   software   systems. 
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I.    INTSODOCTIDH 

A.       THE    PROBLEM 

Software  maintenance  in  Naval  Aviation  Operational 
Flight  Prograis  (OFP)  has  become  very  difficult  and  costly. 
Costs  will  continue  to  rise  as  new  weapon  systems  and 
mission  requirements  are  integrated  into  the  various  opera- 
tional aviation  platforms.  Changes  which  reflect  hardware 
improvements,  mission  changes,  or  improved  algorithms  are 
time  consuming  and  can  lead  to  long  delays  in  delivery  of 
the        updated        system.  Software        maintenance         problems 

concerning  the  OFP  are  compounded  by  the  environment  in 
which  the  OFP  must  operate.  This  operational  environment  is 
a  real  time,  limited  hardware,  limited  support  resources, 
and    very   tightly   time  constrained.  The   original   design   of 

the  OFP  itself  was  often  poor  and  little  documentation  is 
available  to  the  maintenance  team.  The  OFP  is  written  in 
either  assembly  language  or  a  very  low  level  programming 
language.  Changes   are     made   under      a      strict   time      table. 

Before  any  redesign  or  implementation  of  a  change  to  an  OFP 
may  begin,  a  large  effort  must  be  expended  to  fully  under- 
stand the  OFP  and  the  impact  the  proposed  change  may  have  on 
the  entire  program.  Testing  is  a  time  critical  task  which 
consumes  a   significant  amount   of   maintenance   resources. 

The  maintenance  effort  is  further  complicated  by  a  lack 
of  trained  system  personnel.  Personnel  turnover  at  the 
software  maintenance  activities  has  been  approximately  ten 
percent  per  year.  System  programmers  take  on  average  three 
years  to  train  before  they  able  to  be  assigned  the  implemen- 
tation of  a  significant  change  to  an  OFP.  During  this 
period     the  system      programmer      may      be    able      to      accomplish 
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little  useful  work  for  the  maintenance  activity.  Due  to  tha 
generally  poor  documentation  and  the  complex  code  of  most 
OFPs  there  are  only  a  handful  of  pesple  who  fully  understand 
a  particular  DFP.  Less  of  these  kay  personnel  would  result 
in  a  severe  reduction  in  the  capability  of  the  software 
maintenance  activity  to  continue  at  acceptable  production 
rates.  There  is  no  improvement  in  the  availablity  of  compe- 
tent   system  personnel  predicted   in   tha  near   future. 

Due  to  the  unique  problems  prasented  to  maintenance 
activities  by  the  characteristics  of  aviation  software, 
maintenance  costs  are  very  significant.  Fiscal  1984  oper- 
ating buget  for  maintenance  of  six  aircraft  OFPs  at  Naval 
Weapons  Center ,  China  Laka,  California,  is  over  16  million 
dollars.  This  figure,  while  seemingly  high,  represents  only 
75  percent  of  the  reguested  budget.  Resources  are  limited 
and  the  situation  is  not  likely  to  improve.  Saveral  major 
proposed  solutions  have  been  suggested  to  improve  the 
productivity  and  the  guality  of  tha  maintanance  effort. 
Thase        suggestions        range  from        complicated        software 

development/maintenance  environments  to  complete  rewrites  of 
tha  flight  software  itself.  Budget  limitations  will  prevent 
any  of  these  major  proposals  beiag  realized  in  the  near 
future. 

B.       THESIS    OUTLINE 

This  thesis  focuses  en  the  two  areas  where  rapid 
improvement  in  the  maintenance  effort  seems  possible;  docu- 
mentation and  testing.  A  set  of  software  tools  and  method- 
ologies which  are  currently  availabla  and  which  would  have  a 
significant  impact  on  these  problem  areas  are  outlined.  Tha 
software  tools  represent  an  affordable  strategy  for  the 
maintenance  activities  to  improve  the  maintenance  of  current 
flight   software    systems. 
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C.  THESIS    0R3ANIZATI0N 

The  remaining  chapters  are  organized  in  the  following 
manner.  A  scenario  tracing  the  development  and  maintenance 
of  an  operational  aircraft  system,  the  A-6  Intruder  OFP,  is 
presented  in     Chapter  Two.  A  detailed      background   of     the 

aviation  software     maintenance   problem      is   given.  Chapter 

Three  gives  a  brief  discussion  of  a  lifecycle  model  for 
aviation  software  maintenance  in  conparision  with  a  standard 
application   program      lifecycle   model.  Software   tools      are 

defined  and  discussed.  Unfeasible  solutions  are  explored. 
Chapter  Four  discusses  software  maintenance/development 
environments.  A  software  development  environment  which  is 
in  use  by  the  Naval  Air  Development  Center,  (NADC)  , 
Warminster,  Pennsylvania,  is  discussed.  A  set  of  tools  and 
methodologies  which  center  on  two  areas  of  OFP  maintenance 
and  are  felt  to  have  the  greatest  iapact  on  the  productivity 
and  quality  of  OFP  maintenance  are  outlined. in  the  next  two 
chapters.  In  Chapter  Five  the  first  of  these  areas,  docu- 
mentation, is  discussed.  Chapter  Six  covers  the  second 
areas,  OFP  testing.  The  thesis  concludes  with  suggestions 
for    future   development  of  OFPs. 

D.  HESEARCH   METHODOLOGIES 

1 .      Literature 

Manual  and  automated  searches  of  the  literature 
produced  a  limited  amount  of  information  concerning 
embedded,  real  time  computer  systsms.  Less  was  found  on 
maintenance  of  the  software  used  in  these  systems.  An  auto- 
mated search  of  government  research  topics  dating  back  six 
years  using  maintenance,  real  time  and  embedded  systems  as 
keywords  produced  an  impressive  work  summary.  Upon  closer 
examination,  most  research  listed  was  not  directly  appli- 
cable to  the  emphasis  of   this   thesis. 
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Noteworthy  work  dealing  specifically  with  a  Navy 
tactical  aircraft  (A-7  light  attack)  OFP  redesign  has  been 
ongoing  under  the  direction  of  the  Naval  Research  Laboratory 
[Ref.  1].  In  this  study,  not  yet  oomplete,  the  OFP  for  the 
A-7  was  redesigned  using  software  sngineering  techniques  of 
modularity,        information      hiding,  formal      specification, 

abstract  interfaces,  and  cooperating  sequential  processes. 
The  study  is  at  the  pcint  that  testing  both  in  ground  simu- 
lators and  flight  tests  is  ready  to  commence.  It  will  not 
be  known  if  the  recoded  OFP  will  psrform  as  rejuired  until 
these  tests  are  complete.  The  study  offers  interesting 
insights  into  the  problems  associated  with  flight  software 
systems   as   they    are    now    designed. 

Definitions  of  the  critical  concepts  of  software 
maintenance,  software  environments,  and  the  software  life- 
cycle  are  readily  available  in  the  literature.  Lientz  and 
Swanson  [Ref.  2]  contains  an  excellent  definition  of  process 
of  software  maintenance  in  large  application  program 
systems.  Fjeldstan,  Hamlen,  Bristow  and  Van  Horn  provided 
further  definitions  used  for  software  maintenance  [Ref.  3], 
[Ref.  5],  [Ref.  4].  Guidance  in  tie  area  of  software  envi- 
ronments was  found  in  articles  by  Howden  [Ref.  6],  Bristow 
[Ref.    4],        and    Wasserman      [Ref.    7].  Also      the    Naval      Air 

Development  Center  provided  an  interesting  discussion  of 
their  development/ maintenance  environment,  FASP  (Facility 
for  Automated  Software  Production)  ^Ref.  8].  The  model  for 
the  software  lifecycle  was  developed  from  Boehm  [Ref.  9]. 
The  maintenance  lifecycle  was  taken  from  Parikh  and 
Zveginitov  [Ref.  10].  The  definition  of  a  software  tool  was 
taken  from  work  conducted  by  the  National  Bureau  of 
Standards    (NBS)    [Ref.   11]. 
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2*      Laboratory   V  ists 

A  wealth  of  information  and  ideas  was  gathered 
during  trips  by  the  author  to  the  primary  Navy  Flight 
Software  Activities  on  the  West  Coast,  Naval  Weapons  Center 
(NWC)  ,  China  Lake,  California  and  Pacific  Missile  Test 
Center  (PMTC)  ,  Point  Mugu,  California.  The  personnel  who 
must  daily  face  the  unenviable  task  of  performing  the  main- 
tenance on  the  flight  software  for  all  of  the  Navy  attack 
and  fighter  aircraft  were  able  to  give  detailed  descriptions 
of  their  problems  and  suggestions  for  improvements.  A  tour 
of  the  facilities  at  both  activities  helped  the  author  to 
gage    the   extent    of    resources  available. 

A  conference  attended  by  representatives  from  all 
three  Navy  Flight  Software  Labs  ani  a  group  of  researchers 
from  various  acadsmic  communities  was  held  5-7  October  1983 
at   the      Naval  Postgraduate    School.  Each    Software      Lab   was 

given  the  opportunity  to  present  wiat  rhey  felt  were  their 
everyday  problems  in  dealing  with  flight  software  mainte- 
nance and  their  ideas  for  future  research.  The  conference 
turned  out  to  be  both  stimulating  and  an  excellent  source  of 
information. 
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II.     BACKGROOHD 

A.  IHTBODUCTIOH 

This  chapter  traces  the  development  and  current  mainte- 
nance of  a  typical  mature  flight  software  system,  the  A-6E. 
The  primary  Navy  software  maintenance  activities  are  identi- 
fied. The  chapter  concludes  with  discussion  of  the  unique 
problems  associated  with  real  time,  embedded  aviation  soft- 
ware   systems. 

B.  A-6E    FLIGHT    SOFTWARE   HISTORY 

The  A-6  Intruder  is  an  all  weather,  carrier  based  jet 
powered  attack  aircraft  built  by  Grumman  Aerospace 
Corporation,  Long  Island,  New  York.  Its  primary  mission 
definition  is  the  accurate  delivery  of  sizeable  ordinance 
loads  and  close  air  support  to  ground  units  under  all 
weather  conditions.  Since  its  initial  design,  it  has  taken 
on  other  roles  as  a  carrier  based  tanker,  electronic  warfare 
platform  and  delivery  vehicle  foe  the  Harpoon  antiship 
cruise   missile.  Many   new    weapon      and    sensor     systems   have 

been  added  to  the  aircraft  since  initial  production.  These 
include  laser  guided  munitions,  Heat  Seeking  Antiradation 
Missile  (HARM)  ,  Forward  Looking  Infrared  Sighting  System 
(FLIR),  and  the  Harpoon  Missile.  It  is  capable  of  carrying 
both    nuclear     and  conventional   weapons.  It   is      a   subsonic 

aircraft  operated  by  the  Navy  and  the  Marine  Corps  from  both 
land  and  aircraft  carrier  based  squadrons.  The  attack 
configuration  of  the  aircraft  is  manned  by  a  two  man  crew, 
pilot  and  bombadier/navigat or  (B/N)  .  The  aircraft  was  first 
flown  in  1959  and  even  though  the  production  line  for  the 
A-6  has  been  closed  it  is  planned  to  have  an  operational 
lifespan   well   beyond   the   year    2000. 
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The  aircraft  has  onboard  a  single,  CP3  computer  with  32k 
words  of  memory.  The  computer  takes  part  in  processing  data 
that  is  involved  in  nearly  every  aspect  of  the  operational 
of  that  aircraft.  Navigation,  weapon  system  management, 
weapon  release  solutions,  radar  input  processing,  and  elec- 
tronic warfare  functions  are  all  processed  in  some  manner  by 
the  onboard  flight  computer.  Data  is  input  from  several 
areas  of  the  aircraft,  processed  and  continuously  displayed 
to  the  pilot  and  B/N.  The  computer  is  not  necessary  to  fly 
the  aircraft  but  without  it  the  A-5  becomes  essentially  a 
jet  powered  World  War  Two  era  bomber.  All  major  changes  in 
weapon  capabilty  and  mission  assignment  have  to  be  in  some 
manner  incorporated  into  the  hardware  and  software  carried 
onboard.  The  Operational  Flight  Program  (OFP)  is  the  soft- 
ware loaded  into  the  random  access  memory  of  the  onboard 
aircraft  computer  that  processes  the  various  input  and 
display  functions. 

Grumman  Aerospace  was  responsible  for  the  initial  devel- 
opment, coding,  integration  and  testing  of  the  OFP.  After 
acceptance  of  the  aircraft  for  fleet  operations,  Grumman  was 
contracted  to  perform  all  software  maintenance  on  the  OFP. 
This  maintenance  consists  of  removing  errors  found  in  the 
OFP  and  the  incorporation  of  enhaacements  to  the  aircraft 
system  into  the  flight  software.  Any  change  in  mission 
definition  for  the  aircraft  must  also  be  reflected  in  the 
OFP.  Grumman  held  the  contract  for  maintenance  until  1978, 
when  Naval  Weapons  Center  (NWC),  China  Lake,  California  was 
tasked  responsibility  for  all  maintenance  functions  of  the 
OFP.  Currently  most  actual  redesign,  coding  and  testing  of 
updates  to  the  OFP  are  performed  by  personnel  assigned  to 
NWC;    some   work    is   contracted  out,    primarily   to  Srumman. 

Entire  OFP  updates  are  sent  to  operational  squadrons 
approximately  once   every      year  and   a    half.  Only   safety  of 

flight  or  severe   mission   reducing     software   errors  are   given 
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immediate  attention  between  scheduled  OFP  updates.  There  is 
a  method  provided  for  squadrons  to  submit  desired  changes 
and  report  OFP  operating  problems  to  NWC.  A  formal  review 
of  desired  changes  to  the  OFP  is  conducted  by  the  Navy 
yearly  with  squadron  and  software  maintenance  personnel  in 
attendance. 

There  are  many  more  enhancements  desired  by  the  opera- 
tional squadrons  than  are  able  to  be  funded  for  incorpora- 
tion into  future  OFP  updates.  Some  enhancements  are  not 
able  to  be  adopted  due  to  the  nature  of  the  computer  system 
itself.  The  system  is  hardware  limited.  The  OFP  itself 
fills  all  available  memory  of  the  onboard  computer.  Major 
changes  are  possible  only  by  degraling  another  mission  area 
or   by  increasing  computer  performance. 

C.       H1VT   SOFTWARE   ACTIVITIES 

Outlined  above  is  the  history  of  one  Navy  tactical 
aircraft  and  its  flight  software  system.  All  other  Navy 
aircraft  have  a  similar  history  concerning  OFP  development 
and      current  maintenance.  There      are     three  primary      Navy 

Flight  Software  activities.  Naval  Air  Development  Center 
(NADC) ,  Warminister,  Pennsylvania,  is  responsible  for  P-3C, 
S-3Ar  and  LAMPS  Antisubmarine  mission  aircraft  software. 
Pacific  Missle  Test  Center  (PMTC) ,  Point  Mugur  California 
performs  maintenance  on  the  F-14A  Fighter,  EA-6B  Electronic 
Warfare  platform,  and  various  missle  system  software.  Naval 
Weapons  Center  (NWC)  ,  China  Lake,  California,  in  addition  to 
the  A-6E,  has  responsibility  for  the  FA- 18  Fighter/Attack, 
A-<*M,  AV-8B,  A-7E,  and  0H1-J  attack  aircraft  OFP  mainte- 
nance. In  all  cases  primary  OFP  development  was  done  by  the 
prime  system  contractor  and  maintenance  of  the  software  was 
picked  up  at  a  later  date  by  one  of  the  software  activities 
listed  above. 
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D.       AVIATION  SOFTWARE   MAINTENANCE   PROBLEMS 

In  the  following  sections  the  unique  problems  which 
render  flight  software  in  real  tine,  embedded  systems  so 
difficult  and  costly  to  maintain  are  outlined  and  dicussed. 
Nearly  all  areas  covered  are  unique  to  flight  software  and 
are  in  addition  to  the  normal  difficulties  encountered  in 
standard  application   program   maintenance. 

1  -      Platform 

In  every  case  the  Operational  Flight  Programs  are 
run  on  computer  systems  carried  onboard  high  performance 
tactical  aircraft.  Space  for  hardware  and  support  systems 
is  limited.  Primary  importance  is  placed  on  aircraft  weapon 
load  and  endurance  capabilities.  The  fact  that  most  Navy 
tactical  aircraft  are  operated  from  aircraft  carriers 
further  defines  and  shapes  the  physical  design  of  the 
aircraft.  Operating     an      aircraft      at      sea     subjects     the 

airframe  and  internal  components  to  severe  stress  during 
catapult  launches  and  arrested  landings.  Initial  design  of 
the  flight  hardware  system  is  often  constrained  within  phys- 
ical space,  electrical  power,  and  air  conditioning  support 
limitations  before  the  hardware  is  selected.  Once  the  hard- 
ware has  been  selected,  the  software  is  designed  within 
hardware  and  mission   requirements  of    the   aircraft. 

2.      Aircraft   Lifespan 

When  the  A- 6  was  originally  designed  in  the  late 
1950's  the  aircraft  was  never  envisioned  to  have  a  lifespan 
until  the  end  of  the  century.  The  lifespan  of  the  aircraft 
will  approach  forty-five  years.  That  is  equivalent  to  a 
World  War  Two  aircraft  being  flown  today  in  a  front  line 
squadron.  The  flight  software  and  the  ability  to  change  it 
to        reflect        new        aircraft       capabilities        and        mission 
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requirements  allows  the  aircraft  to  remain  viable  for  such  a 
previously  unheard  of  length  of  time.  Aircraft  are  very 
expensive  and  as  higher  performanca  demands  are  placed  on 
the  newly  designed  airframe  and  tactical  systems  the  expense 
will  grow.  The  high  development  and  purchase  cost  forces 
the  Defense  Department  into  a  position  in  which  the  aircraft 
are  utilized  as  long  as  feasible.  This  posture  on  the 
utilization  Df  these  aircraft  well  beyond  their  original 
designed  lifespan  has  several  affects  on  the  flight  soft- 
ware. Mission  requirements  and  weapon  systems  which  were 
never  contemplated  in  the  original  aircraft  and  flight 
computer  design  are  being  incorporated  into  the  aircraft 
system  years  later.  The  hardware  wiich  very  well  might  have 
been  state  of  the  art  during  the  design  of  the  system  can 
quickly  become  the  limiting  factor  as  major  changes  to  the 
OFP  are  requested  and  implemented.  Changes  to  the  hardware 
is  not  an  easy  task  and  is  more  expensive  than  the  high 
software  maintenance  costs.  In  the  years  since  its  initial 
design  and  introduction  to  the  fleet  the  A-6  has  undergone 
one  major  computer  hardware  update,  while  the  software  is 
undergoing   constant    review    and  change. 

3.      Independent    Activities 

High  performance  aircraft  have  a  large  number  of 
very  independent  devices  which  must  operate  in  order  for  the 
aircraft  to     perform   its     mission   properly.  These  devices 

include  sensors  measuring  various  flight  parameters  such  as 
altitude,  air  speed  and  angle  of  attack.  Radar,  infrared 
sighting,  electronic  warfare  and  weapon  guidance  systems, 
are  among  the  many  devices  that  flight  computer  systems  must 
also  react  to.  Input  from  the  aircrew  must  be  incorporated 
into      the   flight      system   processing      as    well.  Interfacing 

these  devices  and  inputs  is  a  complicated  task.  This  inter- 
face   impacts  greatly   on  the      software   engineer  attempting  to 
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modify  a  flight  software  system.  Not  only  mast  he  under- 
stand the  program  itself,  but  he  also  must  understand  the 
interfaces  and  the  affect  a  modification  will  have  on  these 
interfaces.  This  problem  is  prevalent  enough  that  managers 
of  both  Navy  software  activities  that  were  visited  expressed 
a  need  for  system  engineers  rathar  than  strict  computer 
software  engineers.  it  was  felt  that  the  aircraft  systems 
are  complicated  enough  that  it  is  easier  to  train  a  systems 
engineer  to  program  rather  than  train  the  programmer  to  be 
an   aircraft   system   engineer. 

•■      Concurrent    Activities 

Not  only  are  there  large  nunbers  of  activities  oper- 
ating independently,  but  these  activities  are  also  concur- 
rent in  their  operation.  All  of  the  interfaces  with  sensors 
and  data  input  are  constantly  updated  so  the  program  can 
perform  as  required.  Timing  considerations  in  the  update  of 
these  activities  in  critical.  Input  from  the  flight  crew 
which  is  bursty  in  nature  must  be  processed  so  that  it  is 
handled  in  a  timely  manner  and  does  not  degrade  the 
remaining  processing.  Display  of  reguired  information  for 
the    flight      crew   must  be      constantly    updated.  The   display 

must    be   accurate  and   in  real  time. 

5 .      Real  Time 

High  performance  tactical  aircraft  operate  in  very 
hostile   conditions.  Complicating   the   software      problem  is 

the  high  speed  that  the  aircraft  flys  while  in  the  hostile 
environment  in  order  to  enhance  its  survivability.  This 
mandates  that  the  processing  of  data  in  the  flight  computer 
system  must  be  done  in  a  real  time  manner.  The  definition 
of  real  time  for  flight  systems  does  not  eguate  to  the  defi- 
nition for  a  banking  database  systen.  Single  CPU  cycles  can 
become   paramount.      An  aircraft   traveling   at   450    knots  at   two 
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hundred  feet  in  altitude  requires  that  updates  from  the 
onboard  computer  be  timely  indeed.  A  delay  of  milliseconds 
can  cause  the  delivered  weapon  to  miss  the  target  entirely 
or  loss  of  the  aircraft  itself.  Every  change  incorporated 
must  consider  every  possible  affect  on  the  timing 
constraints   of   the   program. 

6.      Reliability    and   Re  cover  ability. 

The  degradation  of  one  aspect  of  the  flight  software 
system  must  not  allow  the  loss  of  the  aircraft.  The  expense 
of  the  aircraft,  aircrew  and  weapons  requires  high  reli- 
ability in  the  flight  software  system.  The  system  must  also 
be  able  to  recover  from  loss  of  input  data  resulting  from 
battle  damage  and  continue  to  operate  in  a  degraded  mode. 
The  software  must  be  protected  against  hardware  failures  as 
well.  Failure  of  the  entire  system  must  only  occur  when  the 
aircraft  is  damaged  to  the  point  of  crew  abandonment. 
Further  the  system  cannot  tolerate  a  requirement  to  restart 
the  program  due  to  a  system  fault  interrupt  or  program  crash 
caused  by  a  software   error. 

7  •      Program   Complexity 

Due  to  the  timing  constraints  placed  on  the  OFPs, 
mos-  are  coded  in  either  assembly  language  or  a  very  low 
level  programming  language  such  as  3MS-2  (P-3C)  or  Metaplan 
(F-14).  The  ability  to  perform  various  software  engineering 
programming  techniques  commonly  used  in  higher  level 
languages   is  lost.  The   original  design   of      the    program   is 

often  not  modular.  The  lack  of  modularity  coupled  with  the 
ad  hoc  fashion  in  which  changes  have  been  made  through  the 
years  has  left  the  OFP  code  extremely  complex,  k  great  deal 
of  effort  is  required  to  merely  comprehend  the  OFP  before 
changes  are  even  designed  much  less  implemented.  The  impact 
of   a    change     to   a   particular   piece      of   OFP   code   may      have   an 
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impact  on  an  entirely  different  unrelated  section  cf  code. 
A  case  cited  during  one  of  the  laboratory  visits  concerned  a 
minor  change  to  a  section  of  code  which  dealt  with  naviga- 
tion of  the  aircraft  resulting  in  the  inability  to  release 
any  weapons.  The  results  of  changss  to  the  code  is  poorly 
understood  until  the  code  is  actually  changed  and  testing  of 
the  revised  OFP  is  begun.  As  has  been  well  documented  in 
the  literature  this  a  very  expensive  time  to  discover  rede- 
sign   errors. 

The  design  of  newer  systems  such  as  the  FA-18 
Fighter /Attack  aircraft  will  show  improvements  in  the  ease 
of  conducting  software  maintenance  on  the  flight  software. 
The  A-6E  has  five  identifiable  nodules  which  have  been 
implemented  during  the  last  five  years  of  maintenance  by 
NWC,  the  FA-18  OFP  which  was  written  by  Hughes  Corporation 
of  Long  Beach,  California  shows  a  marked  improvement  in 
modularity  with  over  one  hundred  identifiable  modules.  The 
situation  seems  to  have  improved  much  over  the  twenty  years 
between  the  design  of  the  A-6  and  the  FA-18.  The  FA-18  OFP 
isr  however,  coded  in  assembly  langauge  due  to  real  time 
reguirements  of    the    flight    software   system. 

8 .      Documentation 

All  Navy  software  activities  tasked  with  OFP  mainte- 
nance had  one  common  complaint.  That  complaint  centers 
around  the  lack  of  useful  documentation  received  from  the 
original  designer  of  the  flight  software.  While  the  entire 
subject  of  documentation  is  subject  to  debate  as  to  its 
proper  form,  what  is  commonly  turnsd  over  to  the  Navy  from 
the  development  contractor  is  severely  lacking.  Even  in  the 
newest  systems  (FA-18  and  AV-3B)  the  documentation 
received  from  the  contractor  has  not  been  as  extensive  as 
the  maintenance  acitivity  desires.  Usually  a  program 
listing   is  the    primary  documentation    received.        Maintenance 
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activities  find  themselves  not  having  accurate  performance 
requirement  documents  on  the  aircraft  itself  or  specifica- 
tion requirements  for  the  OFP.  Documentation  carried  today 
has    largely   been      generated    by   the   maintenance  activity. 

A  problem  related  to  documentation  was  identified  by 
Neetz,  [Ref.  12],  of  PMTC  concerning  the  difficulty  of  the 
maintenance  programmer  in  understanding  the  desired  change 
to   an     OFP    submitted    by     fleet    personnel.  The    information 

contained  in  lost  deficiency  reports  was  often  found  to  be 
limited  and  this  slowed  the  problem  identification  process. 
He  also  found  that  the  managers  felt  that  feedback  from  the 
fleet  was  adequate  while  the  technical  engineers  felt  it  was 
not    adequate. 

9 .  Training 

As  stated  earlier  each  software  activity  faces  high 
personnel     turnover.  Many     studies   have     shown      that     the 

required  numbers  of  computer  capable  system  engineers  are 
not      being   produced.  Competition  with      industry    is      keen. 

After  a  system  engineer  is  trained  adequately  he  may  be 
offered  a  position  with  the  contractor  of  the  system  he  is 
trained  on  at  a  hefty  salary  increase.  Training  of  a  new 
system  engineer  is  an  extremely  slow  and  difficult  process. 
Adding  to  the  problem  is  that  often  while  this  training 
period  is  ongoing  this  engineer  may  not  be  directly  involved 
in   any      productive    work.  Since   the      numbers  of      qualified 

personnel  is  not  expected  to  grow  quickly  and  there  is  no 
training  institute  for  training  engineers  on  specific 
aircraft  systems,  all  training  mast  continue  to  be  done 
internally. 

10.  Hardware   Limitations 

As  stated  earlier,  the  hardware  design  of  the  flight 
computer  systems   was   often   considersd      state   of   the   art   when 
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first   installed    in   the  aircraft.  As  the   aircraft    ages   and 

more  capabilities  are  added  to  the  aircraft,  the  hardware 
can  quickly  become  the  limiting  factor  in  implementing 
enhancements  to  the  OFP.  The  A-6  was  designd  with  16K  of 
available  RAM.  Reserve  memory  was  quickly  allocated  to  new 
functions  implemented  in  the  OFP  within  the  first  few  years 
of  fleet  operations.  A  major  upgrade  to  32K  was  accom- 
plished in  1968,  this  quickly  met  with  the  same  fate  as  the 
original  16K  implementation.  The  DFP  of  many  Navy  aircraft 
have      zero   percent      memory      and      throughput   reserve.  This 

factor  leads  to  further  complication  of  the  OFP  code  when 
changes  are  made.  Additions  of  particularly  large  changes 
to  OFP  code  may  require  that  certain  functions  of  the  OFP  be 
either  degraded  or  dropped  altogether.  Simply  adding  larger 
amounts  of  reserve  memory  has  not  been  the  answer  due  to  the 
difficulties  in  making  hardware  changes  to  the  aircraft 
itself.  Also    there     are    many      more   enhancements      awaiting 

implementation  that  would  quickly  be  incorporated  if  memory 
were    made  available. 

11.    Aircraft   Populations 

One  problem  facing  the  software  maintenance  activi- 
ties as  a  whole  is  the  limited  number  of  aircraft  of  a 
particular  type  being  flown.  At  any  given  time  there  are 
approximately  200  A-6  aircraft  assigned  to  operational 
squadrons.  The   number      of  computers      and   flight      programs 

represented  by  that  number  is  not  large  enough  to  warrant 
large  expenditures  for  major  software  redesigns  and  large 
support  environments  which  would  lower  maintenance  costs. 
Aircraft  are  expected  to  be  fully  supported  after  production 
lines  have  closed  and  the  number  of  aircraft  and  funding 
support  is  dropping.  The  A-7  production  line  has  closed  but 
the  largest  change  to  its  OFP  was  recently  conducted  by  NWC 
when  the  HARM  system  was  incorporated  into  the  aircraft 
inventory. 
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12.  Human  Factors 

Another  obstacle  facing  the  maintenance  programmer 
dealing  with  aviation  programs  is  the  human  factors  associ- 
ated with  input  and  display  of  data  for  the  flight  crew. 
Human  factors  is  defined  as  the  functional  task  area  which 
is  concerned  with  the  aspects  of  human  performance  that 
affect  or  are  affected  by  the  software  [Ref.  13}.  The  area 
to  which  this  definition  refers  falls  primarily  under  the 
input  and  display  of  data  to  the  flightcrew.  Changes  to  the 
program  which  affect  display  are  especially  critical.  The 
display  must  be  presented  in  such  a  manner  that  it  does  not 
require  undue  effort  for  the  flight  crew  to  comprehend  it. 
Little  is  understood  in  this  field  of  computer  science. 
Research  is  currently  being  conducted  at  PMTC  dealing 
specifically  with  human  factors  as  they  relate  to  flight 
programs.  Programmers  implementing  changes  to  an  OFP  must 
constantly  keep  in  mind  the  affect  of  their  change  on  any 
display  data.  Guidelines  for  the  affect  on  the  flight 
computer  operators  is  not  based  on  scientific  fact  rather  it 
is   based  on   operator    feedback. 

13.  Military   Standards 

Currently  all  software  maintenance  activities 
operate  under  several  Military  Standards  (Mil-Std)  which 
guide  the  development  and  maintenance  of  the  programs  they 
cover.  Primary  in  importance  to  the  flight  software  systems 
is  Military  Standard  1679A  (February  1983)  which  covers 
Weapon      Systen      Software   Development.  Unfortunately     this 

standard  while  good  in  its  intent  does  not  address  the  real 
world  situations  of  OFP  development  and  maintenance. 
Several  of  the  active  OFPs  were  written  ten  to  fifteen  years 
prior  to  Mil-Std  1679  first  being  issued  (1978)  .  Concepts 
covered   by    Mil-Std    1679   were  not    applicable  when    these   older 
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OFPs  were  designed.  Mil-Std  1679a  requires  the  use  of  a 
high  level  programming  language  in  all  weapon  systems.  As 
has  been  mentioned  earlier,  it  is  not  possible  to  code 
current  OFPs  in  a  high  level  Language  due  to  timing 
constraints.  NWC  personnel  have  expressed  some  concern  over 
the  requirements  outlined  in  Mil-Sti  1679  and  the  difficul- 
ties in  following  it  on  an  OFP  as  complex  as  the  A-6«s  has 
become.  PMTC  personnel  have  no  real  complaints  about  it. 
But  it  should  be  remembered  that  they  are  working  on  some- 
what newer  systems  to  which  it  can  be  more  readily  applied. 
A  review  of   Mil-std    1679  is   contained   in   [  Ref .    14]. 

14.  Deadlines 

The  software  activities  maintaining  flight  software 
on  operational  aircraft  often  find  themselves  facing  severe 
deadline  requirements.  Safety  of  flight  or  primary  mission 
degrading  problems  with  the  OFP  are  processed  on  an  imme- 
diate basis  requiring  the  possibility  that  all  other  OFP 
maintenance  tasks  be  dropped.  If  the  redesign  of  the  OFP  is 
not  properly  done  and  the  error  is  not  discovered  until  late 
in  testing  phases,  nearly  the  entire  process  must  be 
repeated  and  delays  in  OFP  updates  may  be  experienced.  In 
order  to  meet  strict  deadlines  oertain  update  features 
cannot  be  accomplished.  This  constant  time  deadline  influ- 
neces  the  performance  of  the  maintenance  effort  throughout 
its    cycle. 

15.  OFP  Testing 

Before  a  revised  OFP  can  be  considered  safe  to 
flight  test  extensive  ground  testing  is  completed.  This 
testing  requires  massive  support  facilities  in  the  form  of 
flight  simulators.  The  target  aircraft  computer  is  loaded 
with  the  revised  OFP.  The  support  facilities  suuround  and 
interface      with    the      target    system      suppling      input   data     to 
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exercise     the     OFP.  The      support      facility     measures      the 

performance  of  the  OFP  under  the  simulated  fligh-  condi- 
tions. Because  of  the  complexity  of  the  OFP  code,  poor 
documentation,  and  high  reliability  required,  testing  is  the 
most  expensive  of  the  operations  performed  on  the  OFP  during 
a  maintenance  change.  Little  is  known  on  the  exact  method 
to  test  the  code  to  yield  meaningful  test  results.  The 
nature  of  the  OFP  code  itself  and  the  mission  it  must 
perform  renders  the  testing  of  the  code  even  more  difficult 
than    normal. 

16.    Scope  of   Maintenance  Changes 

Industrial  application  programs  normally  face  a  five 
percent  per  year  code  growth  due  to  software  maintenance. 
The  maintenance  of  OFPs  produces  something  on  the  order  of 
twenty  five  percent  code  change  per  OFP  update.  The  shear 
amount  of  code  required  to  make  the  changes  during  an  update 
cycle  contributes  to  the  difficulty  of  the  maintenance. 
After  the  completion  of  two  to  three  OFP  updates  the  code 
may  be  significantly  changed  from  the  orginal  program.  If 
not  well  documented,  the  high  volume  of  maintenance  changes 
will   render        the   program     almost   unfathomable.  A   problem 

faced  by  the  maintenance  personnel  is  that  the  code  has 
already  gone  through  several  updates  prior  to  being  turned 
over    to   the   Navy. 
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III.    MAINTENANCE    jjf    NAVAL    AVIATION    FLIGHT    SOFTWARE 

A.  IHTHODOCTION 

The  question  of  why  software  is  the  important  product  in 
aviation      flight   computer      systems   is      addressed    first.  A 

general  description  of  ths  software  lifecycle  and  the  main- 
tenance lifecycle  as  related  to  aviation  systems  is  given. 
Proposed  solutions  to  the  flight  software  maintenance 
problem  are  given.  The  following  definitions  are  outlined: 
software  tool,  software  maintenance,  lifecycle  model,  and 
maintenance  lifecycle  model. 

B.  WHY    SOFTWARE? 

When  first  designed  and  built,  real  tine  embedded 
computer  systems  had  their  functional  capabilities  primarily 
embodied  in  the  electronics  with  software  playing  a  minor 
role      controlling      ancillary      functions.  Demand      on     the 

performance  of  these  systems  requirad  that  they  be  designed 
with  a  greater  degree  of  inter-system  communication  between 
devices.  This  has  caused  the  software  of  these  systems  to 
shift  from  a  minor  role  to  one  where  the  system  functional 
definition  is  in  the  software  and  the  electronics  are  only  a 
means   of  providing   for  execution. 

Boehm  [ Eef -  9],  defines  software  as  the  entire  set  of 
programs,  procedures  and  related  documentation  associated 
with  a  system.  The  Software  Technology  for  Reliable  Systems 
(STARS)  Program  Strategy  Handbook  lists  in  addition:  defini- 
tions, designs,  testing  materials  and  maintenance  instruc- 
tions [Ref.  13].  Software  is  what  controls  the  computer  and 
allows  it  to  accomplish  so  much.  The  hardware  in  the  actual 
computer      systems  of      the      tactical      aircraft   undergoes      few 
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changes   throughout    the     lifespan   of   the   aircraft.  Yet   the 

flight  software  system  is  expected  to  be  constantly  upgraded 
as  additions  and  enhancements  to  the  aircraft  system  are 
implemented.  These     changes   are      primarily      reflected     in 

software. 

The  U.S.  Air  Force  experienced  a  situation  that  illus- 
trates the  case  for  software  in  embedded  computer  systems. 
F-1 1 1  tactical  aircraft  were  operated  in  two  basic  models. 
In  one,  avionic  systems  were  implemented  in  analog  devices 
while  in  the  other  the  same  systems  were  implemented  in 
digital  devices.  The  Air  Force  was  tasked  to  keep  the  capa- 
bilities of  both  models  equal.  Several  changes  to  the 
systems  were  tracked  and  it  was  determined  that  changing  the 
hardware  implementations  was  roughly  fifty  times  as  costly 
as  the  software  changes  [Ref.  13].  The  cost  and  time  to 
design  a  software  change  is  roughly  equal  in  cost  and  time 
to  design  a  hardware  change.  Hardware  however,  requires 
management  of  individual  changes  and  physical  copies  of  the 
new  hardware  be  maintained.  Software  is  much  easier  to  copy 
on  multiple  tapes  and  quickly  load  into  the  individual 
computers.  The  difficulties  in  implementing  changes  with 
hardware  are  evident  when  compared  to  implementing  the  same 
changes   in   software. 

PMTC  personnel  point  out  the  case  of  the  F-14  as  another 
example  of  why  i nprovements  to  the  aircraft  computer  system 
are    best      carried  out     in  software.  F-14   OFP      changes  are 

promulgated  approximately  every  two  years  at  a  total  cost  of 
roughly  two  million  dollars  for  each  change  development  and 
implementation.  There  are  approximately  400  F-14  aircraft. 
Implementing  the  changed  OFP  in  each  aircraft  consists  of 
merely  loading  the  new  OFP  tape  into  the  aircraft  computer 
system  memory.  The  cost  of  a  new  OFP  is  approximately  5,000 
dollars  per  aircraft.  Anyone  experienced  in  making  equip- 
ment   alterations     to   military     aircraft    knows      5,000  dollars 
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will  buy  very  little.  When  considered  against  the  cost  of 
an  individual  F-14  (3  $30  million)  implementing  flight 
computer  system  changes  through  software  is  very  cheap.  If 
all  of  the  corrections  and  enhancements  to  the  system  had 
been  made  in  hardware  the  costs  would  have  been  in  the 
billions   of   dollars. 

C.       SOFTWARE  MAINTENANCE 

Fjeldstad  and  Hamlen  define  software  maintenance  to  be 
incorporation  of  changes  to  existing  programs,  using  or 
modifying  an  existing  approach  or  design  then  understanding 
and  modifying  or  expanding  existing  program  logic  [Ref.  3]. 
Lientz  and  Swanson  describe  the  primary  types  of  maintenance 
[Ref.    2]. 

1.  Corrective  Maintenance:  correction  of  errors  intro- 
duced in  the  software  through  improper  logic  or  coding 
errors. 

2.  Adaptive  Maintenance:  satisfaction  of  changes  in 
processing  environment.  Input  and  output  requirements 
often  change.  This  case  was  experienced  with  the  A-6E 
system  when  the  aircraft1 s  navigational  suite  was 
upgraded. 

3.  Perfective  Maintenance:  enhancement  of  the  system  for 
increased  performance  and  maintainability .  This  includes 
improvements  to  documentation  and  recoding  to  improve 
program  efficiency.  Again  using  the  A-6E  as  an  example, 
the  aircraft  was  tasked  to  perform  low  level  bombing  from 
two  hundred  feet  vice  five  hundred  feet.  This  change  was 
induced  to  increase  weapon  accuracy  while  also  increasing 
aircraft  survivability  against  heavily  defended  targets. 
This  improvement  in  the  aircraft  mission  definition 
required   extensive  OFP  software  modification. 

Lientz  and  Swanson  in  [Ref.  2]  offer  the  following 
statistics  on  the  allocation  of  maintenance  time.  Twenty 
percent  of  the  maintenance  effort  involved  corrective  main- 
tenance. Adaptive  maintenance  accounted  for  twenty  five 
percent.  Perfective  maintenance  accounted  for  the  rest  of 
the  time  at  fifty  five  percent.  Enhancements  accounted  for 
the  largest  share  of  the  perfective  maintenance  at  forty 
nine    percent  of    the    total  maintenance   effort.      These   figures 
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were  taken  from  a  survey  conducted  of  large  data  processing 
organizations. 

Results  of  an  informal  survey  of  NWC  maintenance  time 
yielded  slightly  different  figures.  Corrective  maintenance 
of  errors  which  are  present  from  the  last  3FP  update  or 
earlier,  only  comprise  five  percent  of  the  maintenance  time. 
Adaptive  maintenance  is  roughly  the  same  as  the  Lientz  find- 
ings at  twenty  percent.  The  largest  share  of  the  mainte- 
nance time  in  OFPs  resides  in  perfective  maintenance.  This 
involves  mainly  optimizing  the  code  and  incorporation  of 
enhancements  to    the   aircraft   system   as  a    whole. 

Van  Horn  defines  another  form  of  software  maintenance, 
that    of      restructuring,      [Ref.    5].  Restructuring   involves 

change  to  the  internal  structure  of  the  program  while  not 
changing  the  overall  external  behavior.  This  is  interest- 
ingly a  consideration  for  improvement  to  many  of  the  older 
OFPs  and  was  implemented  by  the  Naval  Research  Laboratory 
[Ref.    1]   for  the   A-7   OFP. 

D.       SOFTWARE  LIFECICLE 

Figure  3.  1  presents  the  standard  waterfall  software 
lifecycle  as  seen  in  Boehm  [Ref-  9].  This  model  represents 
the  development  of  a  standard  large  scale  application  soft- 
ware   system.      It   is   based  on   two   assumptions: 

1.  Each  phase  of  the  lifecycle  is  culminated  by  a  verifi- 
cation phase  that  attempts  to  eliminate  errors  in  the 
output  of  that  phase.  This  is  expected  to  be  accom- 
plished  prior   to    moving    to   the  next   phase. 

2.  Iterations  of  earlier  phase  products  are  performed  in 
the  next   succeeding  phase. 

Each  phase  of  the  Boehm  Lifscycle  Model  is  briefly 
described   below: 

A.  Feasibility:  Defining  objective  of  the  proposed  soft- 
ware Droduct.  Is  it  feasible  to  be  accomplished?  And 
will  it  be  superior  to  the  system  that  it  is  proposed  to 
replace? 
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B.  Requirements:  A  validated  specification  of  required 
functions,  interfaces  and  performance  aspects  of  the 
proposed  system   is  generated. 

C.  Design:  The  high  level  hardware-software  architectural 
design,  control  structure  and  lajor  data  structures  for 
the  system   are  outlined. 

D.  Detailed  Design:  Complete  verified  specification  of 
the  high  lsvel  design  is  produced.  Precise  algorithms, 
data  structures,  interfaces  and  control  structures  are 
designed.  Several  refinement  steps  are  involved  as 
detail  of  system    is  realized. 

E.  Code:  The  software  portion  of  the  system  is  imple- 
mented in  executable  code.  Testing  of  individual  compo- 
nents  begins. 

F.  Integration:  The  software  product  is  made  functional 
and  is  run.  Individual  components  are  integrated  into 
subassemblies  and  finally  into  the  final  software 
product.  Initial  errors  are  removed  from  software  as 
they   are   identified.      Program   testing   continues. 

G.  Implementation:  The  software-hardware  system  is 
brought  into  initial  operation.  Testing  is  completed  to 
determine  if    the    overall    product   meets    design    objectives. 

H.  Maintenance:  Error  corrections  are  made  to  the  opera- 
tional program.  Perfective  and  adaptive  changes  are 
accomplished    as    needed. 

I.  Phaseout:  A  replacement  system  is  designed  and 
i  mplemented. 

The  system  is  sequential  in  nature  and  the  start  of  any 
phase  assumes  the  completion  of  the  proceeding  phase.  The 
verification  and  validation  part  of  each  phase  is  defined  as 
follows: 

Verification  is  the  process  by  which  the  truth  of  corre- 
spondence between  the  software  itself  and  its  specifica- 
tion  is   assertained. 

Validation  establishes  the  fitness  of  the  software  system 
in  carrying   out    its  intended  operational  mission. 

Boehm  further  states  that  the  lifecycle  as  proposed 
allows  for  a  high  degree  of  control  in  the  configuration 
management  of  the  product.  The  manager  is  able  at  any  given 
time  in  the  development/maintenance  process  to  define  the 
specific  state    of  the  project   in   concrete   terms. 

Once  a  design  strategy  following  the  lifecycle  model  is 
implemented     the        project      baseline      can        be     established. 
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According  to     Boehm    the   three     major    advantages      gained   from 
this    baseline  are: 

1 .  No   changes    are    made  to  the   system    without   agreement   of 
all  interested   parties. 

2.  Higher      threshold      for   changes      will      stabilize      the 
product. 

3.  The  overall  manager  controls   the  configuration   manage- 
ment   process. 

The  lifecycle  model  as  presented  by  Boehm  is  a  well 
known  and  accepted  model.  The  question  remains  just  how 
well  does  the  model  comply  with  real  life  systems.  When 
comparing  this  model  to  the  development  and  maintenance 
lifecycle  of  a  typical  aviation  software  system  it  seems  not 
to  compare  well  at  all.  The  current  method  of  operation  in 
OFP  maintenance  has  the  maintenanca  activity  stepping  into 
the  lifecycle  model  at  the  next  to  the  last  phase.  The 
software  activities  have  in  the  past  had  little  input  into 
the  software  development  process  conducted  by  the  prime 
system  contractor.  There  is  littla  or  no  communication  in 
the  form  of  documentation  when  the  software  activity  assumes 
responsibility  for  maintenance.  The  logic  and  design  meth- 
odologies used  by  the  original  designers  are  lost  to  the 
maintenance  personnel.  The  continuum  of  the  lifecycle  model 
as  proposed  by  Boehm  is  lost  when  the  Navy  begins  mainte- 
nance  of  the  OFP. 

Boehm  also  gives  little  mention  of  the  maintenance  phase 
itself  in  his  discussion  of  the  lifecycle  model.  Several 
studies  have  found  that  the  maintenance  phase  of  the  life- 
cycle  the  most  expensive.  Estimates  range  from  fifty  to 
eighty  percent  of  overall  system  costs  are  involved  in  soft- 
ware maintenance  of  a  large  application  software  system 
[Ref.  2].  A  O.S.  Air  Force  study  estimated  that  software 
costs  during  developemnt  average!  $75  per  instruction. 
During  the    maintenance  of  an   operational   system   the   software 
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costs  increased  to  $U000  per  instruction  [fief.  15]-  This 
trend  is  reflected  in  aviation  flight  software  systems  as 
the   lifespans   for  the  aircraft   they   serve   are   extended. 

E.       HAINTEHAHCE    LIFECICLE 

The  maintenance  phase  can  be  thought  of  as  a  lifecycle 
within  the  overall  lifecycle.  Incorporating  enhancements  to 
a  system  cr  repairing  errors  not  found  during  initial 
testing  phases  will  involve  a  redesign  effort  similar  in 
many  respects  to  the  initial  design  of  a  system.  Parikh  and 
Zvegivtov  (Ref.  10],  review  a  maintenance  process  in  the 
opening  comments  to  a  chapter  in  their  book  dii  Software 
Maintenance.  Figure  3.2  illustrates  this  process.  This 
representation  is  based  on  changes  being  made  to  a  fully 
operational  system.  Their  simplified  maintenance  lifecycle 
is   defined   as  follows: 

1.  Understand  the  Request:  The  user  of  the  system 
reguests  a  change  to  an  operational  system  be  made  by  the 
maintenance  activity.  This  request  is  written  in  a 
langauge  familar  to  the  user.  The  maintenance  programmer 
must  understand  the  request  and  the  current  program  prior 
to   design  of    the    change. 

2.  Transform  Request:  Using  a  description  of  the  existing 
and  requested  systems,  the  differences  between  the  two 
are  sought.  The  process  of  designing  for  the  change 
involves  reducing  the  differences  between  the  existing 
and  the  new  system.  The  existing  system  is  revised  to 
match  the  new  system. 

3.  Specify  Change:  A  Cut  Line  and  Patch  are  specified. 
The  Cut  Line  is  the  section  of  code  to  be  modified.  The 
Patch  is  defined  as  the  new  code  to  be  implemented  which 
reflects  the  new  system  within  the  Cut  Line.  The  selec- 
tion of  the  Cut  Line  is  difficult  because  it  is  selected 
to  minimize  interaction  between  the  existing  system  and 
the  Patch.  Lowering  this  interaction  will  reduce  the 
chances  of  damage  to  other  sections  of  the  program  not 
necessarily  related  to  the  Cut  Line.  Modularity  of  the 
program  is  a  key  aid  in  selection  of  the  Cut  Line. 
Program  complexity  is  another  issue  which  affects  the 
interaction  of  the  Patch  once  inserted  within  the  Cut 
Line. 

4.  Develop  the  Patch:  The  Patch  is  actually  developed  in 
a  programming  langauge  using  standard  development  techni- 
ques. The  ultimate  goal  of  the  Patch  is  the 
accomplishment  of  the  requested  change  to  the  existing 
program.  The  Patch  should  be  designed  such  that  it  will 
fit   within  the  Cut  Line. 
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5.  Test:  The  change  is  installed  and  tested  within  the 
development  environment.  The  Z\it  Line  is  tested  for 
appropriate  switching  between  the  existing  functions  and 
the  new  code.  _  The  impact  of  the  new  code  to  code  ourside 
of  the  Cut  Line  is  identified.  Regression  testing  is 
performed  where   needed. 

$.  .Release:  Once  tests  are  performed  the  updated  system 
is   installed   and   released. 

The  model  for  the  maintenance  oycle  presented  by  Parikh 
and  Zvegivtov  can  be  seen  as  a  refinement  of  the  overall 
lifecycle  presented  by  Boehm.  Its  major  concern  is  in  the 
understanding  of  the  request,  relating  that  knowledge  to  the 
existing  system  and  designing  the  change  such  that  it  will 
not  degrade  the  updated  system.  Interaction  is  addressed 
more    specifically.  It  is      perhaps   optimistic      in    assuming 

that  the  Patch  can  always  be  installed  within  the  Cut  Line. 
Also  the  selection  of  the  Cut  Line  while  difficult  in  a  well 
designed  program  would  seem  nearly  impossible  in  a  complex 
software  system.  The  rather  difficult  and  extremely  large 
area  of  testing  is  given  a  quick  review  in  this  model.  The 
cycle  assumes  several  characteristics  of  the  existing 
program,  such  as  proper  design,  adequate  documentation  and  a 
well    developed      maintenance    environment.  This    may     render 

this  model  somewhat  simplified  for  the  embedded  computer 
system.  A  model  for  the  aviation  software  lifecycle  is 
presented  next. 

F.       AVIATIOH   SOFTWARE   HAINTEHANCE   LIFECYCLE 

The  aviation  development/maintenance  lifecycle  as 
presented  in  Figure  3.3  was  taken  from  a  slide  presented  by 
NWC  personnel.  Further  discussion  was  held  with  maintenance 
personnel  to  determine  how  close  the  real  maintenance  effort 
parallels      this    definition.  The      model   presented      roughly 

follows  the  Boehm  model.  The  aviation  model  is  presented  in 
greater  detail.  Each  phase  is  well  documented  by  required 
submissions  of    reports  and    specifications.         Reviews,    audits 
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and  walkthroughs  are  scheduled  at  several  points  of  the 
model.  Table  I  defines  the  abbreviations  used  to  represent 
the    documentation    and    reviews    shown    in    the    model. 

TABLE   I 
Aviation   Lifecycie   Terms 


Lifecycle    Documentation 

MENS:  Mission   Element  Need   Statement 

SRS:  System  Requirements   Specification 

PPS:  Program  Performance   Specification 

IDS:  Interface    Design   Document 

PDS1 :  Preliminary   Program   Design   Specification 

PDS2:  Program  Design   Spscif ication    (Final) 

DBDD:  Data  Base    Design   Document 

PP:  Program  Package 

PDD:  Program  Description   Document 

SDP:  Software    Development   Plan 

CMP:  Configuration   Management    Plan 

QAP:  Quality   Assurance   Plan 

CPTPL:  Computer    Program   Test    Plan 

CPTS:  Computer    Program  rest    Specification 

CPTPR:  Computer    Program   rest   Procedures 

CPTR:  Computer    Program  Test   Report 

Reviews   and   Walkthroughs 

MMR:  Mission  Requirement   Review 

SRR:  System  Requirements   Review 

SWRR:  Software    Requirements   Review 

PDR:  Prelimina iy   Design    Review 

CDR:  Critical    Design   Review 

MCR:  Module  Code    Review 

FVRR:  Formal  Validation   Readiness  Review 

DRC:  Design  Review  Committee 

FCA:  Functional   Configuration   Audit 

PCA:  Physical   Configuration   Audit 


— _—  j 


The  model  as  presented  is  well  structured  and  well 
defined.  Unfortunately  the  reality  of  what  actually  occurs 
during  development  of  maintenance  code  may  not  be  accurately 
represented  by  this  model.  There  are  several  reasons  for 
this.  In  many  of  the  older  flight  systems  the  exact  process 
of  software  maintenance  was  not  precise  and  was  difficult  to 
define.  Some  of  the  documentations  specified  and  reviews 
presented  in  the   lodel  are      currently   not    being   conducted   in 
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every  flight  software  system.  Ths  model  presented  repre- 
sents a  standard  that  several  of  the  OFP  maintenance  teams 
are  attempting  to  achieve.  What  is  actually  occuring  is 
only    partially    represented    by   this  model. 

Nearly  all  flight  systems  undergo  few  hardware  changes 
throughout  the  lifecycle.  The  hardware  branch  of  the  model 
only  applies  to  new  development  of  an  entire  flight  system 
or  a  major  midlife  modification.  The  year  to  year  software 
maintenance  of  the  OFP  has  the  software  branch  of  the  model 
taking  on  the  most  impact.  New  aiditions  to  the  hardware 
and  complete  changes  are  usually  done  with  hardware  already 
in  use  in  ether  systems.  This  also  significantly  reduces 
the  amount  of  time  spent  in  the  hardware  branch  of  the 
lifecycle. 

The  integration  phase  of  the  aviation  model  represents 
primarily  the  integration  of  the  old  and  new  OFP  code.  The 
complexity  of  older  system  code  makes  this  much  more  diffi- 
cult than  the  integration  of  the  entire  OFP  with  the  system 
hardware.  Also  code  may  be  developed  by  parallel  develop- 
ment activities.  Contractors  are  often  utilized  to  perform 
the  generation  of  portions  of  maintsnance  code.  Since  these 
parallel  redesign  efforts  are  usually  conducted  on  different 
systems,  conversion  of  the  code  developed  outside  may  be 
required  in  order  for  it  to  be  integrated  and  tested  at  the 
Navy    software   facility. 

One  high  level  manager  involved  in  the  maintenance 
effort  on  one  of  the  older  OFPs  told  of  the  reluctance  of 
the  system  engineers  and  programmers  to  adopt  any  standard 
model    for  the   maintenance  process.  They    are  used   to    doing 

it  a  certain  way  that  is  comfortable  to  each  indiviual 
programmer.  A  standard  is  difficult  for  them  to  accept. 
The      stages   are     well  documented.  The      reviews    and      walk- 

throughs require  the  programmer  to  spend  a  great  deal  of 
time      preparing    for      them.  One      programmer   complained     of 
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spending  over  twenty  hours  preparing  for  a  review  on  a  small 
section  of  OFP  code  which  requirsd  one  hour  of  time  to 
recede. 

Even  though  it  may  not  be  exactly  standardized  for  each 
maintenance  team,  the  model  presented  in  Figure  3.3  presents 
a  good  general  representaion  of  what  each  OFP  undergoes  at 
one    time  or   another    during    development  and   maintenance. 

G.        SOFTWARE   TOOLS 

1 .      Definition 

Software  tools  are  defined  by  the  National  Bureau  of 
Standards  [Ref.  11],  as  computer  programs  that  aid  in  the 
specification,  construction,  testing,  analysis,  management, 
documentation  and  maintenance  of  other  computer  programs. 
Shooman  divides  these  many  functions  into  four  broad 
catagories,   [Ref.    16]. 

a.  Program   editing  and  storage 

b.  Program   processors  and   preprocessors 

c.  Program   configuration    and  control 

d.  Testing   and   debugging    processss 

The  purpose  of  a  Software  Tool  is  to  aid  the  programmer  in 
such  a  manner  that  productivity  and  the  product  quality  are 
increased.  They   are     designed   to      be   used      many   times     on 

several  different  projects  within  several  different 
environments. 

In  [Ref.  7]  Wasserman  givas  the  attributes  of  a 
useful  tccl  as   the    following: 


1.  Singularity  of  Purpose:  Tha  tool  should  be  designed 
for  one  primary  use,  carrying  oat  one  well  defined  func- 
tion. 

2.  Ease  of  Use:  The  tool  should  not  burden  the  user.  The 
programmer  should  want  to  use  the  tool  to  increase  his 
productivity. 
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3.  Self  Documenting:  The  tool  should  not  have  large  hard 
copy  documentation  But  instead  lost  documentation  should 
be   in  the  form  of   an  interactive   help   facility. 

4.  Consistency:  Each  tool  should  be  consistent  with  the 
others  of  the  environment  in  which  they  are  contained. 
The  product  of  a  tool  used  earlier  in  the  lifecycle  of 
the  software  should  be  able  to  be  used  by  another  tool 
used  in  a  later  phase.  To  achieve  this  tools  should 
interact  through  common  interfaces.  Tools  within  each 
environment  conform  to  a  set  of  standards  so  that  fami- 
larity   with   one    tccl   will  help  in    learning   another  tool. 

5.  Adaptability:  A  tool  should  be  able  to  adapted  to  some 
user  desires.  The  tool  should  have  several  modes  avail- 
able from  a  basic  generic  mode  up  through  the  full  design 
capability  of  the   tool. 

6.  Local  Intelligence:  The  tool  is  able  to  capture  useful 
data  from  the  environment  in  which  it  is  employed. 
Normally  this  is  stored  to  a  data  base  where  it  may  be 
further  processed  for  documentation  and  configuration 
management   purposes. 

2«      Software  Tool  Os 

There  seems  to  exist  a  general  agreement  within  the 
literature  that  well  designed  software  tools  are  highly 
desirable.  Precise  tool  definition  and  terminologies  are 
not  well  defined.  In  [Ref.  11  ],  a  taxonomy  of  software  tool 
definitions  and  terminologies  are  standardized  in  order  to 
allow  comparision  amcng  different  tools.  Software  tools  are 
large  computer  programs,  which  like  any  other  programs,  face 
the    same      development  and      maintenance    problems.  They   are 

expensive  to  develop  and  may  not  always  meet  the  original 
specifications. 

Other  than  expense  there  are  several  other  reasons 
that      software      tools     have    not      found      wider      use.  Nassi 

[Ref.  17],  lists  several  general  catagories  which  have  hind- 
ered   the  use  of    software  tools. 

a.      General    Nature    of    Many  Tools 

Some  tools  are  very  general  in  their  intended 
use  and  are  not  at  all  suitable  in  some  specific  systems 
without  a  large  modification  effort.  To  develop  a  specific 
tool      for      a     specific     application   may     not      be      worth     the 
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development  costs  when  compared  to  the  savings  it  will 
generate.  This  is  a  common  case  for  lack  of  tool  use  in  the 
aviaticn     software    field.  Some      aircraft   computer      sysrem 

populations  are  low  and  do  not  warrant  the  expensive  that 
development   of   a   tool  for  that   particular  OFP   would   entail. 

b.  Learning   Curve 

Programmers  accustomed  to  working  in  a  certain 
environment  may  find  the  pain  of  learning  a  new  tool  not 
worth  their  effort.  Even  if  the  programmer  can  be  shown  to 
benefit  greatly  from  the  use  of  a  new  tool,  habit  may  make 
the      adoption  of      that     tool  difficult.  A      tool    which     is 

particularly  hard  to  use  or  learn  is  doomed  to  failure. 
Usability  of  the  tool  should  be  such  that  the  programmer  is 
not    encumbered   by   its  use.  It   should   compliment   the    envi- 

ronment  in    which   it    is  used    ,    not   fight    it. 

c.  Functionality 

If  a  tool  is  not  suitable  for  a  specfic  job  it 
may  create  performance  burdens  on  the  system  on  which  it  is 
being  used.  The  overhead  created  by  its  use  should  not  be 
excessive.  The  tool  should  be  reliable  in  that  it  may  often 
be  operating  directly  on  user  source  files  and  the 
programmer   must    be   able  to    trust   in   its   use. 

d.  Integration 

The  integration  within  an  environment  should 
allow  for  the  tool  in  use  to  communicate  easily  with  other 
tools.  The  programmer  will  then  be  able  to  move  smoothly 
back  and  forth  between  stages  as  needed  without  a  great  deal 
of  effort. 
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e.      Tool   Usage  by  Software  Activities 

Coupled  with  the  reasons  cited  by  Nassi  for  the 
limited  use  of  software  tools,  the  flight  software  mainte- 
nance activities  face  other  problems.  Funding  to  purchase 
the      tools     is      not      available.  The      software      activities 

conducting  maintenance  on  the  OFPs  do  use  a  varirty  of  soft- 
ware tools.  Host  seem  to  be  generated  in  house  for  specific 
purposes  within  the  enviroment  of  a  particular  OFP.  They 
are  often  not  portable  to  another  project.  The  use  of  more 
powerful  off-the-shelf  tools  has  also  been  hindered  by 
several   factors.  The   state    of      most  OFPs      currently   would 

require  extensive  reconfiguration  to  allow  the  use  of  these 
tools.  The  worst  problem  is  the  lack  of  documentation. 
Many  tools  developed  by  industry  require  a  well  designed, 
well  documented  program  to  work  with.  An  example  is  the  TRW 
developed  software  tool  SREM  (Software  Requirements 
Engineering  Methodology) .  SREM  requires  that  documentation 
in  the  form  of  an  adequate  set  of  program  requirements  be 
available.  Most  OFPs  do  not  have  such  documentation  and 
thus  cannot  use  SREM  in  the  production  of  flight  software 
code. 

The  environment  of  the  maintenance  effort  for 
the  various  OFPs  differ  from  project  to  project.  None  of 
them  seem  to  be  able  to  support  a  set  of  tools  which  would 
cooperate  and  communicate  during  the  maintenance  process. 
The  work  required  to  set  up  the  environment  and  program  to 
work  with  an  off-the-shelf  tool  has  been  found  in  many  cases 
to  be  excessive.  Internal  development  of  powerful  tools  is 
also    time  consuming    and   may    not    be  feasible. 

The  AV-8/A-4  test  facilty  at  NWC  conducted  a 
survey  of  all  software  tools  in  use  in  their  facility.  The 
results  are  interesting  and  reflect  the  situation  throughout 
most      OFP      maintenance     and    test      facilities.  Forty      four 
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different  tools  were  listed  as  in  use.  Ninty  five  percent 
of  the  tools  were  developed  internally  by  personnel  assigned 
to  the  test  facility.  Twenty  nine  percent  have  the  ability 
to  communicate  with  one  or  more  tools.  Fifty  percent  of  the 
tools  had  no  support  available.  It  is  easy  to  see  that  this 
is  a  long  way  from  the  ideal  situation  many  authors  propose 
for   automated  tool    usage. 

The  maintenance  activities  find  themselves 
unable  to  buy  their  way  out  of  the  OFP  maintenance  problem 
by    designing     or  buying   tools.  Oace   a   software      system  is 

accepted  from  the  developer  the  original  design  and  documen- 
tation may  limit  what  the  maintenance  activity  has  available 
to   improve   the   maintenance   effort. 

H.       PROPOSED  SOLUTIONS 

Many   solutions   have     been    proposed   to   ease     the  software 
maintenance     problem      in     common      application      systems.  A 

smaller  list  of  solutions  have  bean  proposed  for  embedded 
systems.  Solutions  range  from  the  incorporation  of  good 
software  engineering  practices  in  the  design  of  the  software 
to  the  use  of  extensive  programming  environments  throughout 
the    lifecycle   of  the    program.  Host    of   these  solutions  are 

viable  and  would  help  if  they  were  to  be  applied  from  the 
original  design  of  the  software.  Several  of  the  proposed 
solutions  are  outlined.  The  reasons  for  the  nonuse  of  these 
solutions   are   also    cited. 

1 .      OFP   Rewrite 

Many  of  the  flight  software  systems  still  in  use 
were  designed  before  many  of  the  software  engineering  prac- 
tices that  are  today  taken  for  granted  were  in  common  use. 
A  complete  rewrite  of  an  OFP  using  these  technigues  has  been 
suggested  as  a    possible   solution    to   tha    maintenance    problem. 
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This  was  the  idea  behind  the  work  of  the  Nav=l  Research 
Laboratory  [Ref.  1],  in  the  recoding  of  the  A-7  OFP.  The 
use  of  the  software  engineering  technigues  of  modularity, 
information  hiding,  formal  specification,  abstract  inter- 
faces and  cooperating  sequential  processes  were  used  in  the 
updated   OFP     as    it    was  rewritten.  It    is    hoped      that    these 

techniques    will    lead    to   lower   maintenance   costs   of   the    OFP. 

An  entire  rewrite  of  the  DFP  offers  several  clear 
advantages.  It  is  in  fact  considered  the  only  method  to 
assure  lowering  of  maintenance  costs.  Many  maintenance 
personnel  interviewed  about  solutions  to  the  OFP  maintenance 
problem  mentioned  OFP  rewrite  as  tha  best  method  to  show  the 
most    improvement. 

Rewriting  the  OFP  in  either  assembly  language  or  a 
suitable  high  order  language  would  allow  generation  of 
currently  nonexisting  documentation.  The  A-7  rewrite  has 
produced  a  well  documented  program.  A  significant  finding 
of  the  A-7  rewrite  work  was  the  the  importance  of  a  Software 
Requirements  Document.  Its  generation  for  the  A-7  was  very 
time  consuming.  It  might  be  as  important  to  the  maintenance 
function  as  the  modern  software  engineering  principles  used 
in  the  rewritten  OFP.  The  production  of  documentation  in  a 
usable  form  would  have  significant  impact  on  training  of 
system  personnel  as  well  as  the  actual  maintenance  of  the 
program.  The  documentation  could  also  be  designed  with  the 
eventual  use  of  more  extensive  and  supportive  software  tools 
in  mind. 

The  program  itself  would  be  placed  into  a  more  main- 
tainable state  by  incorporation  of  modern  software  engi- 
neering techniques  into  the  redesigned  code.  This  was  the 
ultimate  goal  of  the  NRL  work  on  A-7.  It  is  very  easy  to 
see  conversion  from  the  "spaghetti  code"  that  many  of  the 
OFPs  contain  to  a  modularized  format  would  have  great  impact 
on    the  reduction   of    maintenance      costs.         The   modern    version 
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of  the  OFP  would  also  be  easier  to  test  with  the  reduction 
in   the     complexity   of     the    code.  The   given      state   of     the 

program  may  be  every  bit  as  difficult  to  determine  due  to 
the  complex  nature  cf  the  platform  and  mission  of  the 
program  itself  but  errors  would  much  easier  to  isolate  once 
detected. 

Several  problems  do  exist  in  this  solution.  Costs 
to  accomplish  a  rewrite  are  very  high.  A  complete  rewrite 
of  the  A-6  OFP  is  estimated  by  NWC  personnel  to  cost  upwards 
of  20  million  dollars  and  take  four  years  to  complete.  The 
finished  product  would  reflect  the  state  of  the  OFP  when  the 
rewrite  was  begun.  The  ongoing  enhancements  occuring  in  the 
operational  OFP  would  still  have  to  be  incorporated  in  the 
rewritten  OFP.  Meanwhile  the  existing  OFP  would  have  to  be 
continually  maintained  as  is  currently  practiced.  The  esti- 
mated A-6  OFP  rewrite  cost  represents  more  money  than  the 
entire  yearly  operating  budget  of  the  software  laboratory  at 
NWC.  The  cost  in  time  and  the  personnel  required  to  accom- 
plish the  project  may  in  fact  be  the  determining  factor. 
The  personnel  are  not  available  to  accomplish  the  rewrite 
and  carry  on  normal  maintenance  activities  of  the  opera- 
tional OFP. 

The  lifespan  of  the  aircraft  in  a  particular  modifi- 
cation is  subject  to  change.  The  days  of  the  A-6E  system 
may    be   numbered.  An  F-model    is   under      consideration   which 

would  represent  a  complete  change  in  many  of  the  systems 
from  the  E-model.  The  future  of  the  F-model  is  in  the  hands 
of  Congress.  When  the  F-model  will  come  on  line  and  work 
slowed  on  the  E-model  is  unknown.  If  the  funds  were  avail- 
able to  rewrite  the  A-6E  OFP  it  is  aard  to  imagine  them  used 
to  actually  begin  recoding  work  with  the  possibility  of  a 
major  avionics  and  flight  software  modification  arising  in 
the    A-6F  model. 
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Questions  remain  about  tha  final  product  of  such  a 
rewrite.  Naval  Research  Laboratory  has  not  yet  completed 
its  work  on  the  A-7  OFP  rewrite  four  years  after  the  orig- 
inal completion  date  has  past.  If  the  new  OFP  will  fit  the 
available  hardware  in  the  aircraft  and  perform  as  the  old 
OFP,  remains  to  be  seen  until  after  testing  phases  are 
completed. 

For  the  reasons  outlined  above,  a  complete  rewrite 
of   existing  OFPs   is    not   feasible    at   this   time. 

2-      iii3k  Order    Languages 

A  rewrite  of  an  OFP  is  asually  suggested  to  be 
accomplished  in  a  standard  Navy  approved  high  order  language 
(HOL)  .  Experience  with  OFP  maintenance  by  the  various  soft- 
ware activities  has  shown  that  the  use  of  a  HOL  may  not 
really  be  required.  NWC  personnel  estimate  that  very  little 
of  the  time  spent  on  the  maintenance  of  the  OFP  is  spent  in 
actual  coding  of  the  maintenance  change.  Ignoring  the  soft- 
ware engineering  techniques  that  a  true  high  order  language 
affords,  very  liitle  is  gained  by  recoding  the  OFP.  The 
ability  to  modularize  an  assembly  language  version,  complete 
with  documentation  on  each  module  would  be  as  useful.  The 
use  of  a  high  order  language  also  presents  the  problem  of 
execution  speed.  The  number  of  systems  in  use  is  not  high 
enough  -o  warrant  spending  the  funds  needed  to  write  opti- 
mizing compilers  to  insure  proper  performance  of  the  OFP. 
The  use  of  a  high  order  language  would  be  much  more  suited 
to   a    system   designed    from  the   start   for    its   use. 

Some  interesting  ideas  arise  from  the  use  of  HOLs  in 
OFPs.  While  perhaps  not  suitabls  for  the  coding  of  the 
actual  flight  system  OFPs  at  this  time,  HOLs  have  been  used 
in  documentation.  A  HOL  version  of  the  OFP  is  used  to  help 
the  programmer  gain  a  grasp  of  what  the  program  is  actually 
doing  prior  to  attempting  to  understand  the  very  complex 
assembly  language   version. 
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A  recant  development  is  the  U.S.  Air  Force  decision 
to  recode  the  P- 111  OFPs  in  a  HOL.  The  Air  Force  plans  to 
use    Jovial   in   this    conversion.  Total   costs   for    the   entire 

project  which  includes  conversion  of  all  remaining  aircraft 
to  digital  avionic  systems  is  placed  at  1.1  billion  dollars. 
Jovial  is  considered  suited  well  enough  for  embedded  appli- 
cations that  the  Air  Force  feels  the  money  required  for  the 
conversion   to  a    HOL    written    OFP   is   worth   the   expense. 

3.  Extensive  Environments 

Another  method  to  improve  the  maintenance  effort  of 
a  software  project  is  to  improve  the  techniques  used  in  its 
design     and  implementation.  An   improvement      in    these      can 

easily  be  accomplished  through  the  use  of  an  extensive 
programming  development  and  maintenance  environment.  The 
environment  would  be  used  throughout  the  software  lifecycle 
cf  the  project.  This  is  a  fine  solution  for  new  systems  but 
hardly  the  answer  for  mature  systems  such  as  A-6  and  A-7. 
Cost  is  the  primary  problem.  Howden  [Ref.  6],  outlines  four 
environments     of      increasing  capablities      and     costs.  The 

highest  capabilty  reflected  in  his  proposal  was  designed  for 
embedded  real  time  systems.  He  estimates  the  capital  costs 
at  three  million  dollars.  NADC  experience  with  FASP, 
outlined  in  the  next  chapter,  suggssts  that  this  figure  may 
indeed   be      very    low.  Costs    for      the   physical      environment 

itself  do  not  incorporate  the  modifications  to  a  program  net 
orginally  designed  for  use  with  that  environment.  The  modi- 
fications required  may  involve  effort  equal  in  cost  to  an 
entire  rewrite. 

4,  Adding    Hardware 

Personnel  not  familar  with  OFP  maintenance  see  the 
hardware  as  the  primary  cause  of  OFP  maintenance  problems. 
They      feel   that      the    maintenance      problem   can      be    solved     by 
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addition  of  hardware  capability  through  added  memory  and 
increased  processor  speeds.  If  significant  iacreases  in 
memory  space  are  installed,  the  program  may  be  able  to  be 
partitioned  and  slightly  restructured  to  reduce  complexity 
and  decrease  maintenance  costs.  While  it  is  well  known  that 
costs  of  hardware  have  dropped  signif icantly  with  improved 
technology  and  the  costs  of  software  continue  to  rise,  addi- 
tions of  large  amounts  of  memory  or  increased  processing 
speed  is  not  the  answer  to  the  maintenance  problem. 
Physically  placing  new  or  additional  hardware  into  the 
aircraft  is  very  difficult  and  requires  extensive  study 
before  approval.  Due  to  the  long  process  to  research  and 
approve  changes  to  the  aircraft  itself,  addition  of  even  a 
small   hardware      change  becomes   quits    expensive.  The   older 

aircraft  support  systems  may  not  bs  compatible  with  some  of 
the  newer  hardware  technologies  rendering  the  addition  of 
the      new  hardware      even   more      difficult      and   costly.  When 

memory  additions  have  been  made  in  the  past,  many  new  capa- 
bilities and  weapon  systems  are  aided  which  quickly  fills 
any  newly  available  memory  space.  Merely  throwing  hardware 
at   the   problem   is  not  a   solution. 
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17.    SOFTWARE   ENVIRONMENTS    AND    FASP 

A.  INTRODUCTION 

This  chapter  will  briefly  outline  the  concept  of  soft- 
ware environments  and  review  the  NADC  operated  Facility  for 
Automated  Software  Production  (FASP),  the  only  current 
attempt  at  a  complete  development  and  maintenance 
environment. 

B.  ENVIRONMENT    DEFINITION 

The  concept  of  a  Software  Engineering  Development  and 
Maintenance  Environment  is  outlined  in  [Ref.  7].  The  envi- 
ronment is  generaly  defined  as  the  technical  and  management 
methodologies,  the  hardware,  mode  of  computer  use,  automated 
support  facilities  (tools)  and  the  actual  physical  work- 
space. It  encompasses  every  aspect  of  the  development  and 
support  of  a  software  system.  The  ideal  environment  should 
support  a  development  methodology.  Wasserman  states  that 
this  has  not  generally  been  the  case  in  many  past  efforts. 
It  also  should  support  the  software  system  throughout  the 
entire     software  lifecycle.  A    specfic      definition  of     the 

lifecycle  should  be  incorporated  into  the  design  of  the 
environment.  The  STARS  Program  Strategy  Handbook  gives  a 
broader  definition  of  an  environment  to  include  the 
personnel  assigned    to  use   the   environment. 

A  complete  development  and  maintenance  environment 
should   possess    the    following  characteristics: 

1 ..  Complete  Lifecycle  Coverage:  The  methodology  supported 
by  the  environment  should  cover  the  entire  lifecycle.  A 
means  for  software  system  design  is  followed  by  a  method 
for  the  code  design  and  implementation.  The  environment 
also  supports  the  software  system  through  the  maintenance 
phase. 
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2.  Ease  of  Transition  Between  Phases:  Building  on  the 
support  of  the  lifecycle,  each  phase  within  the  lifecycle 
should  be  able  to  be  identified  and  traversed  by  method- 
ologies employed  by  the  envirDnment.  The  transition 
should  be  painless  and  allow  the  programmer  to  move  back- 
wards  as  needed   to  correct   or   change   earlier   work. 

3.  Ease  of  Use:  The .environment  should  be  designed  such 
that  the  programmer  is  not  burdened  by  its  use.  The 
personnel  assigned  to  the  project  should  be  able  to  learn 
the  environment's  methodologies  without  undue  effort. 
The  training  of  new  personnel  would  be  made  easier, 
allowing  them  to  become  productive  members  of  the  teams 
more   guickly. 

4.  Repeatability:  An  ideal  environment  is  general  enough 
to  be  used  several  times  on  functionally  similar  but 
different  actual  projects.  The  effort  in  creating  a 
complete  environment  tailored  only  to  a  specific  system 
is   lost    when    that    system    is   no   longer   in   use. 

5.  Automated  Support:  Since  the  ultimate  goal  of  an  envi- 
ronment is  the  increased  productivity  and  guality  of  the 
product,  the  selection  of  the  automated  support  facili- 
ties is  critical.  The  tools  selected  are  automated  to 
the  extent  that  an  increase  in  productivity  is  aained 
through   their   use. 

Boehm  cites  a  study  in  which  the  COCOMO  Model  for 
Software  Cost  Estimation  was  used  to  demonstrate  the  effec- 
tiveness of  the  use  of  a  properly  designed  environment. 
Figure  4.1  shows  the  estimated  improvements  in  software 
productivity  versus  software  cost  driver  attributes.  From 
the  graph  presented  in  Figure  4.1  several  of  the  software 
cost  driver  attributes  can  be  seen  to  impact  greatly  on  the 
flight  software  problem  as  defined  in  Chapter  Two  of  this 
thesis.  Most  notably,  schedule  constraints,  turnaround 
time,  software  tools,  storage  constraint,  required  reli- 
ability, program  complexity  and  personnel  capability  greatly 
influence  the  maintenance  effort  of  OFPs.  Many  of  these 
factors  are  out  of  direct  control  of  the  maintenance 
personnel  due  to  the  nature  of  the  flight  programs  and  the 
development     practices     used.  It   appears      from      the      data 

presented     by      Boehm     that    concentration      in     the      areas     of 
increasing   personnel   capability   through    tools  and    methodolo- 
\  gies    will   have    the    greatest    impact  on    increasing   maintenance 
'.productivity.  Interestingly,        testing   problems      are      not 

"\ddressed      directly      by     Boehm   as     a      Software     Cost      Driver 
►tribute. 
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Figure   4.1        Multiplicative  Software   Productivity   Factors. 
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C.       FASP 

FASP  (Facility  for  Automated  Software  Production)  was 
designed  and  implemented  by  NADC  in  recognition  of  the  high 
costs  and  complex  nature  of  developing  and  maintaining 
weapon  system  software.  FASP  is  currently  used  in  the  main- 
tenance of  antisubmarine  aircraft  software.  It  was  designed 
to  be  used  in  the  development  and  maintenance  of  any  weapon 
software  system.      Table   II    gives   the    Navy   standard  computers 

TABLE   II 
FASP  Language    and  Computer   Support 


Navy   Standard   Computers 


i 

I 

I 

|  AYK-14 

|  AYK-10 

I  UKY-20 

OKY-7 
OKY-32 


Navy    Standard    Programming    Languages 


SPL/1    and   SPL 
CMS-2M    and    C1S-2Y 
MACRO-20   and    ULTRA-32 
FORTRAN    and   COMPASS 


and  Navy  standard  programming  languages  supported  by  FASP. 
The  total  lifecycle  of  the  software  system  is  intended  to  be 
supported   by  FASP.  It  was   designed    such      that    the   primary 

development  contractors  are  able  to  use  FASP  throughout  the 
development   process.  The    maintenance    activity    is      able   to 

inherit  frcm  the  contractor  a  complete  software  system 
developed  on  the  same  support  facility  it  will  be  maintained 
on. 

Two  types  of  facilities  are  provided  through  the  FASP 
system.  The  first  is  for  software  integration.  Integration 
facilities   consist      of  laboratory   simulations   of      the  target 
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aircraft  computer  system.  The  intBgration  facility  is  used 
in  hardware/software  integration.  It  serves  as  the  hardware 
configuration  baseline  and  is  also  used  in  the  determination 
of  the  human  factors  involved  in  system  design  and  mainte- 
nance. Change  proposals  to  a  software  system  can  be  quickly 
evaluated  by  use  of   the  simulated  target   computers. 

The  software  production  facility,  the  second  facility 
provided  by  FASP,  uses  an  approach  to  software  development 
in  which  the  same  facilities  are  used  for  both  development 
and      maintenance.  The  software     production      facility     was 

designed  to  be  shared  by  several  saftware  systems  for  their 
entire  lifecycles.  Improved  software  tools  provided  by  FASP 
increase  programmer  productivity  and  product  quality. 
Management  visibility  of  the  software  configuration  is 
provided.  Maintainability  is  increased  through  the  support 
of   structured  programming  and   modularity  techniques. 

An  integrated  database  which  contains  project  and 
management  data  is  ultilized  extensively.  Maintenance  and 
development  is  divided  within  the  database  into  distinct 
processes  each  with  a  measurable  output.  Input  and  output 
of  each  phase  is  stored  in  the  database  where  it  is  automat- 
ically configured  into  management  reports  for  each  project. 
The  project  manager  is  able  to  set  production  figures  into 
the  database  which  FASP  will  automatically  track  and  report 
on.  The  configuration  control  provided  by  FASP  allows  more 
accurate  cost  estimates   on    software   production. 

Automation  provided  by  FASP  reduces  the  production 
effort  in  the  labor  intensive  areas  of  development  and  main- 
tenance. Increased  programmer  productivity  will  offset 
increasing  programmer  costs  by  decreasing  computer  time 
required  in  these  areas.  FASP  performs  the  following  auto- 
matic operations: 

1.  Translation    of     simple    user  commands  into      many    oper- 
ating system    commands 

2.  Maintenance  of   the  database. 
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3.  Execution   of    regression     testing   on   specific   software 
modules    and    report   cf   rest   results. 

4.  Interactive  program  editing   and   testing 

These  automatic  features  free  the  programmer  from  many 
routine  tasks  and  allows   greater   use    of    program   librarians. 

FASP  provides  a  formalized  structure  which  contains  the 
software  tools  necessary  to  increase  production  and  quality 
of  the  final  product.  A  Software  Emulator  which  simulates 
the  target  military  computer  on  the  FASP  host  computer  is 
provided.  Unit  tests  of  software  modules  can  be  performed 
at  earlier  stages  of  the  development  or  maintenance  process 
in  the  simulated  environment  in  which  it  will  operate.  The 
cost  of  software  errors  are  reduced  by  locating  and 
correcting  them  earlier.  Testing  is  also  able  to  begin  well 
before  the  implementation  phase.  An  Automatic  rest  Analyzer 
determines  which  paths  through  the  project  program  have  been 
traversed  and  instruments  the  sour-e  code  without  hindering 
performance.  Results  are  automatically  stored  in  the  FASP 
database.  From  there  management  reports  on  path  tests  are 
generated.  FASP  also  supports  Automatic  Regression  Testing. 
All  module  test  results  are  maintained  in  the  FASP  database. 
Each  module  has  a  complete  test  history  available.  A  change 
to  a  module  will  automatically  retest  all  test  cases 
affected  by  the  module  change  and  store  the  results  to  the 
database. 

Facilities  for  implementation  of  FASP  are  extensive. 
The  host  system  consists  of  two  CDC  6800  and  two  CDC  CYBER 
175  computers.  This  large  capacity  system  enables  several 
projects     to     be      maintained  by      FASP      concurrently.  Each 

programmer  is  able  to  use  a  virtual  target  machine  emulated 
by  the  FASP  host  computers.  Many  virtual  machines  are  able 
to  be  utilized  concurrently.  By  combining  the  support  of 
many  projects  on  one  system,  significant  physical  plant  cost 
savings    are   realized.        The    large   computing   capacity    is  also 
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available  to  handle  urgent  maintenance  deadlines  without 
significantly  reducing  normal  development  and  maintenance 
activities. 

FASP  allows  the  use  of  nearly  any  computer  to  tie  into 
its  facilities.  Contractors  not  physically  located  at  the 
FASP  sight  are  able  to  utilize  FASP  during  the  development 
phase  of  the  project  software.  As  the  maintenance  of  the 
software  is  turned  over  to  NADC,  a  smooth  transition  from 
the  development  phase  to  the  maintenance  phase  is  insured. 
The  maintenance  activity  has  available  extensive  documenta- 
tion   from   development  to  aid   maintenance. 

FASP  is  the  first  attempt  at  an  integrated  software 
development  and  maintenance  environment  directed  at  embedded 
real  time  computer  systems.  It  has  met  with  considerable 
success  on  the  three  flight  software  sysrems  developed  and 
maintained   on   FASP.  Its    success   is    based     on   the    facility 

being  used  throughout  the  entire  software  lifecycle.  FASP 
would  not  be  particularly  suitable  for  use  in  systems  in 
late    maintenance      phases   such   as      A-6    or    A-7.  These   older 

OFPs  would  require  extensive  rewrites  and  documentation 
before  the  FASP  system  could  be  utilized.  FASP  is  best 
suited  to  be  used  from  the  initial  development  and 
throughout   the   remainder   of   the  software  lifecycle. 
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V.    IHPHQYIHG   OFP    MAIN1JNAHCJ    THBQOGH    DOCUMENTATION 

A.  INTRODOCTIOH 

Thus  far  this  thesis  has  covered  the  background  material 
to  understanding  the  unique  problems  related  to  software 
maintenance     of      real     time,  embedded      aviation      software 

systems.  Definitions     have     been        presented      and      models 

compared.  FASP,  an  environment  in  use  by  one  software 
activity  has  been  presented.  The  next  two  chapters  of  the 
thesis  presents  tools  and  methodologies  which  can  be  used  to 
improve  the  maintenance  effort  with  modest  expenditures  in 
time    and   money.  Focus   is    directed    in    the     two    areas    where 

the  most  improvement  in  the  maintenance  effort  seems 
possible,  docamentat ion  and  testing.  Both  of  these  subjects 
were  brought  up  time  after  time  in  licussions  with  OFP  main- 
tenance personnel.  It  is  likely  when  improvements  in  these 
areas  are  adopted,  ether  areas  of  the  problem  will  show 
improvement   also. 

The  suggestions  presented  in  the  next  two  chapters  by  no 
means  offer  a  quick  easy  solution.  The  problem  has  devel- 
oped over  a  number  of  years  and  is  much  too  complex. 
Solutions  will  not  come  easy  no  matter  what  price  is  paid. 
What  follows  is  primarily  based  on  interviews  with  the  main- 
tenance personnel  conducted  in  an  informal  manner  during  the 
three  trips  to  the  two  West  Coast  Navy  flight  software 
activities,    during   conferences  and   over   the   telephone. 

B.  DOCUHEHTATIOH  IMPBOTEMENTS 

Every  software  activity,  every  person  involved  in  OFP 
maintenance  mentioned  one  aspect  of  the  OFP  software  to  be 
severely  lacking.    That  area   is  documentation.    In  nearly 
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every  case  the  documentation  the  maintenance  personnel 
received  from  the  prime  contractor  when  OFPs  were  turned 
over  to  Navy  was  poor.  Many  of  the  OFP  contracts  were 
written  before  any  guidance  from  the  Navy  was  available  on 
documentation.  In  seme  flight  systems  the  requirement  for 
documentation  was  left  out  in  order  to  save  initial  develop- 
ment funds.  The  already  extremely  difficult  task  of  main- 
taining complex  OFPs  is  made  nearly  impossible  by  the  lack 
of   good   documentation. 

Because  of  poor  documentation  many  of  the  other  problems 
of  maintaining  the  OFP  software  develop.  Training  new 
personnel  is  made  even  harder  as  it  takes  a  great  deal  of 
time  for  someone  to  understand  a  system  in  which  there  is 
poor  reference  material.  The  new  personnel  find  themselves 
learning  primarily  through  hands  on  experience.  They  learn 
the  program  on  the  fly  as  they  implement  changes.  This 
slows  the  maintenance  effort  and  affords  an  opportunity  to 
introduce   errors  into  the   revised  code. 

Poor  documentation  causes  the  entire  update  cycle  of  the 
OFP  to  be  longer  than  would  be  needsd  with  proper  documenta- 
tion. Experienced  personnel  find  themselves  spending  a 
significant  amount  of  time  merely  trying  to  understand  the 
existing  OFP  code  prior  to  designing  a  maintenance  change. 
Because  of  the  effort  required  to  comprehend  the  existing 
OFP,  the  largest  portion  of  time  spent  in  the  maintenance 
cycle   is   spent    in  the  design   phase. 

Lack  of  documentation  currently  inhibits  most  mainte- 
nance teams  from  using  many  off-the-shelf  software  tools  and 
methodologies.  Several  personnel  interviewed  named  tocls 
that  would  help  their  effort  significantly  but  were  unable 
to  use  due  to  the  difficulty  involved  in  setting  up  the  OFP 
documentation  to  allow  the  tools  use.  Most  tools  are 
designed  to  be  used  with  a  well  documented  product.  Because 
of  this,    most  of  the   tools    used  are   developed   internally   and 
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are  not  able  to  be  shared  between  different  projects.  This 
has  lead  the  support  systems  and  methods  used  by  the 
different  OFP  projects  becoming  increasingly  disjoint  over 
the  years.  Each  has  become  its  own  seperate  enitity.  This 
can    partly    be   blamed    on   poor   documentation. 

Difficulty  in  understanding  tha  code  when  designing  a 
maintenance  change  leads  to  difficulty  in  determining  mean- 
ingful program  test  reguirements  for  the  revised  code.  A 
poorly  designed  change  due  to  a  lack  of  understanding  of 
what  the  program  is  suppose  to  do  leads  to  greater  testing 
costs.  The  number  of  design  errors  would  decrease  if  the 
design  engineer  and  programmer  had  quality  documentation 
available. 

Suggestions  of  what  to  do  first  center  on  a  definition 
of  documentation.  Documentation  is  defined  in  a  broad  sense 
as  the  method  of  giving  information  about  a  computer  program 
or  system  so  that  a  reasonably  trained  person  is  able  to 
understand  the  system,  use  it  and  nodify  it  to  fullfill  new 
objectives.  This  definition  is  a  modified  version  of  one 
presented  by  Edmund  Berkely  (Ref.  18].  The  point  taken  from 
this  definition  is  documentation  allows  the  person 
utilizing   it  to    understand   the   system. 

There  are  many  arguments  as  to  the  most  effective  format 
of  documentation.  It  is  an  area  of  computer  science  that  is 
still  under  extensive  study  and  interfaces  directly  with 
study  of  the  human  learning  process.  This  thesis  will  offer 
no  profound  insights  into  the  proper  format  of  documenta- 
tion. It  will  accept  only  the  premise  that  workable  docu- 
mentation  is  critical  to  the   maintenance   of   OFPs. 

Again  citing  an  active  OFP  maintenance  effort,  the  A-6E, 
OFP  documentation  received  from  Grumman  was  felt  to  be 
totally  inadequate  for  the  task.  It  has  several  major  prob- 
lems which  limit  its  use.  First,  it  consists  only  of  the 
OFP    program  listing      and  a    set   of   math      flow   diagrams.        The 
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math  flow  diagrams  consist  roughly  in  the  format  of  crude 
flowcharts  containing  mathematical  representations  of  what 
is  occuring  in  the  program  code.  They  are  very  difficult  to 
read  for  someone  not  intimately  familar  with  them.  Each 
flow  symbol  contains  a  large  array  of  cryptic  symbols  which 
are  difficult  to  follow.  The  math  flows  exist  on  paper  and 
have  been  copied  so  many  times  that  individual  symbols  are 
faded  and  extremely  difficult  to  identify.  changes  to  a 
program  involves  converting  the  representation  of  the  change 
into  the  math  flow  format,  redrawing  by  hand  the  pages 
affected  and  inserting  the  change  into  the  hard  paper  copy. 
This  leaves  significant  opportuntiss  for  error.  As  the 
documentation  stands  it  is  totally  inadequate  for  training 
an  engineer  or  programmer.  It  also  does  not  allow  use  of  a 
set  of  capable  software  tools  in  a  meaningful  maintenance 
environment. 

Two  very  important  forms  of  dDCumentation  are  missing 
from  the  A-6  OFP  inventory.  Currant  Software  Requirements 
and  Aircraft  Performance  Specification  Documents  are  not 
available.  The      maintenance   programmer      cannot      determine 

exactly  what  the  program  is  suppose  to  do  prior  to 
attempting  to  glean  how  the  OFP  actually  does  it.  A  soft- 
ware redesign  is  significantly  slowed  by  the  effort  required 
to  understand  the  current  program.  Errors  are  introduced 
only  because  the  redesigned  code  is  nor  what  the  maintenance 
change  called  for.  Aircraft  performance  requirements  are 
equally  important  to  determine  the  parameters  involved  in  a 
redesign  effort.  They  are  also  inportant  in  understanding 
the  OFP  code  itself.  Accurate  information  on  what  the 
aircraft  is  doing  during  certain  phases  of  operation  helps 
tell  the  engineer  what  is  happening  inside  of  the  OFP.  For 
example,  what  the  program  expects  to  see  from  a  certain 
sensor  at  a  certain  time  is  determined  from  the  aircraft 
performance   specifications    document. 
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The  suggestions  for  improving  the  documentation  do  not 
involve  a  complete  OFP  rewrite.  The  documentation  improve- 
ments will  center  around  the  OFP  as  it  currently  stands. 
These  suggestions  are  aimed  at  improving  the  maintenance 
effort   without    very    large  expenditures     of   resources. 

1.      Electronic   Documentation    Storage 

The  first  effort  at  improvement  of  the  documentation 
would  be  to  change  the  format  on  which  it  is  kept, 
automating  the  storage,  retrieval  and  reducing  the  time 
involved  to  record  a  change  would  hslp  greatly.  The  chance 
of  not  incorporating  a  change  to  one  of  the  the  many  copies 
of  the  paper  documentation  is  reduced.  Electronic  storage 
also  allows  the  programmer  to  quickly  retrieve  the  documen- 
tation he  requires. 

The  A-6  software  personnel  are  taking  steps  in 
exactly  this  direction.  A  Documentation  Librarian  has  been 
hired  to  deal  with  the  paper  documentation  and  enter  it  into 
an   electronic     storage  facility.  One   person     or   group     of 

persons  assigned  only  to  the  maintsnance  of  the  documenta- 
tion will  allow  closer  control  of  the  accuracy  of  that  docu- 
mentation. The  programmer  will  not  need  to  burden  himself 
with  the  requirement  to  enter  changes  to  the  documentation 
of   code   he    has   revised. 

Many  tools  abound  which  would  allow  the  documenta- 
tion to  be  stored  electronically.  A  database  could  be 
implemented  on  existing  facilities  or  maintained  on  an 
expanded  small  network  of  microcomputers.  The  exact  tools 
used  are  not  as  important  as  the  concept  of  maintaining  the 
documentation  electronically  to  allDw  easy  access,  modifica- 
tion   and  storage   of    large  amounts   of    data. 

Characteristics  of  a  systen  chosen  should  reflect 
the    following: 
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1.  Ease  of  Use.  The  system  should  be  easy  to  use  so  as 
not  to  discourage  the  user.  Idsally  the  system  would  ba 
incorporated  online  within  the  system  that  the  programmer 
normally  works,  as  FASP  does.  Realistically  a  stand 
alone  machine  which  does  not  require  excessive  effort  to 
use  is   adequate. 

2.  Speed  of  Access.  The  systsm  need  not  be  such  that 
mstanteous  access  is  achieved.  Most  microcomputer  data- 
base systems  with  adequate  memory  allow  the  user  to 
access  text  and  print  it  out  without  a  long  wait.  The 
number  of  personnel  using  the  system  is  not  large  enough 
that   concurrent   multiple   users   are   a   significant    problem. 

3.  Adequate  Backup.  This  may  seam  incredibly  obvious  but 
it  must  be  addressed  if  the  documentation  is  to  be  stored 
in  an  electronic  form.  A  system  employed  on  a  mainframe 
may  utilize  the  operating  system  backup  procedures 
normally  used.  Smaller  microsystems  would  require 
multiple  copies  be  maintained  on  tape  and  a  procedure  to 
insure  timely   backups   implemented. 

4.  Consistency..  Related  to  the  backup  question,  consis- 
tency involves  insuring  that  all  copies  of  the  data  are 
consistent  with  each  other.  This  must  be  accomplished  if 
the  electronic  documentation  is  to  be  meaningful.  Again, 
the  exact  system  employed  to  hold  the  documentation  would 
yield  the  method  used  to  maintain  consistency.  As  the 
database  to  contain  the  current  documentation  would  not 
be  extremaly  large  the  system  to  maintain  consistency 
need   not   be    automated. 

5.  Graphical  Representation  Capability.  conversion  of 
the  current  documentation  wouli  involve  working  with 
paper  copy  which  contains  many  graphical  representations 
and  symbols.  The  documentation  should  not  require  major 
redefinition  or  restructuring  if  the  cost  of  maintaining 
it  in  an  electronic  form  is  to  be  held  to  reasonable 
level.  The  difficulty  to  use  certain  symbols  contained 
in  the  math  flow  diagrams  has  slowed  the  effort  at 
entering  the  A-6  documentation  into  the  Xerox  Star  system 
that  they  are  using.  Switching  from  graphical  to  text 
modes  is  constantly  required  to  properly  position  the 
symbols    required    by  the    math   flow    documentation. 

The   graphical  representataion    problem   may    be  the    key 
to   selecting     the  documentation   storage   system.  A   careful 

survey  should  be  conducted  of  the  data  to  be  entered  into 
the  new  system  prior  to  selecting  the  storage  system  to  be 
used.  The  system  selected  should  be  able  to  easily  repre- 
sent any  symbol  rsquired  in  the  documentation.  Some  symbols 
contained  in  the  current  documentation  may  be  able  to  be 
changed  to  allow  the  use  of  a  particular  storage  system. 
This  problem  may  limit  the  ability  to  use  some  of  the  micro- 
computer databases  available.  It  calls  for  careful  study  to 
insure  the  stored  data  is  accurate  and  that  new  data  can  be 
entered    without    excessive  effort. 
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Costs  to  implement  the  electronic  storage  of  the 
documentation  vary  with  the  volume  to  be  stored  and  its 
current  hard  copy  format.  Rough  estimates  of  the  cost  to 
purchase  a  capable  microcomputer  system  with  adequate  hard 
disk  storage,  three  to  four  terminals,  adequate  graphical 
representation  capabilities,  backup  facilities,  software 
(purchased  if  possible)  and  printers  range  from  20,000  up  to 
50,000  dollars.  This  figure  represents  a  very  small  invest- 
ment. Once  implemented  it  could  provide  significant  savings 
in  the  years  to  come.  Cost  for  more  extensive  database 
systems  to  be  used  on  larger  conputer  facilities  range 
higher.  The  cost  of  implementing  the  Xerox  Star  system  for 
storage  of  A-6  documentation  will  run  approximately  100,000 
dollars.  The  personnel  assigned  to  use  the  documentation 
feel    that      this    money     is  well   spent.  While  input      of   the 

current  documentation  is  painful,  the  payoff  in  the  long  run 
will    be   well  worth    the  initial  investment. 

After  the  system  to  store  and  manipulate  the  docu- 
mentation has  been  implemented,  the  next  step  is  to  enter 
the  documentation  required  by  the  lifecycle  chart  that 
figure  3.3  outlined.  This  would  of  course  involve  adapting 
the  lifecycle  methodology  illustrated  in  figure  3.3  as  a 
standard  throughout  the  maintenance  process.  The  documenta- 
tion required  at  each  step  is  then  formated  to  be  entered  in 
the  storage  system  after  the  completion  of  each  phase.  A 
documentation  history  is  maintained  for  each  maintenance 
change.  The    format     is      fixed      and   once      the      maintenance 

personnel  become  familar  with  it,  lifecycle  phase  documenta- 
tion generation  and  use  will  becoae  easier.  The  system 
should  have  enough  capacity  so  that  change  documentation  can 
be  stored  online  between  OPP  updates  to  allow  easy  access  if 
required  after  completion  of  an  update.  When  the  next  OF? 
update  cycle  is  started,  the  documentation  is  also  available 
to   help   comprehend   the  current   state    of   the  OFP.      Once   a   new 


64 


update  cycle  is  completed  the  previous  update  documentation 
is  stored  in  an  archival  storage  system  for  program  history 
purposes.  This  would  enable  all  change  documentation  to  bs 
maintained  in  order  to  be  able  to  trace  the  OF?  change 
history. 

2.      Software   Requirement   Document 

The  next  step  in  improving  the  documentation  of  OFPs 
would  be  the  generation  of  a  Software  Requirements  Document 
(SRD)  .  Work  done  by  the  Naval  Research  Laboratory  [Ref*  1], 
yielded  a  workable  Software  Requirements  Document  for  rhe 
A-7   OFP.  This   document  was      generated   in      preparation   for 

recoding  of  the  OFP.  The  generation  of  such  a  document  for 
other  existing  flight  systems  need  not  entail  recoding  the 
OFP.  The  following  outline  of  tha  format  of  the  Software 
Requirements  Document  was  modeled  from  the  A-7  work  done  for 
the   Naval  Research   Laboratory. 

The  primary  purpose  of  the  Software  Requirements 
Document  is  to  describe  the  externally  visible  behavior  of 
tha  OFP  without  desribing  the  implementation.  The  SRD 
assumes  the  hardware  to  be  static;  this  is  a  valid  assump- 
tion for  embedded  aircraft  systems.  Interface  characteris- 
tics are  seperated  from  software  requirements.  Interface 
characteristics  will  change  only  if  the  hardware  changes, 
while  software  requirements  will  change  only  if  the  mission 
requirement  of  the  OFP  changes.  The  document  is  maintained 
as  the  reference  for  what  tha  aircraft  OFP  does. 
Implementation    is      not  addressed.  As    an      example   of      what 

might  be  contained  in  the  document,  it  might  explain  that 
during  final  approach  to  an  aircraft  carrier  landing, 
certain  symbols  are  displayed  on  the  pilot's  heads  up 
display  (HDD),  as  opposed  to  the  symbols  that  are  displayed 
during  a  bombing  run.  How  the  computations  occur  that 
\  determine  where  to  place  the  symbols  on  the  HOD  is  not 
addressed. 
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As  was  done  by  ths  NRL  work,  the  format  is  set  up  to 
enhance  readability      and  is   easily  referenced.  Tables  are 

used  extensively  to  make  look  up  of  specific  items  easy  and 
enable   the     rsader   to  easily      spot   missing   data.  To   allow 

table  usage,  a  standard  set  of  definitions  which  represent 
long  phrases  or  complex  conditions  are  given  symbols.  They 
are  referenced  in  a  data  dictionary  contained  within  the 
document. 

The  format  of  the  Software  Requirements  Document  is 
discussed  next,  it  was  based  on  the  design  of  the  A-7 
Software   Requirements  document. 

a.  Aircraft    Computer 

The  A-7  Software  Requirements  Document  begins 
with  a  short  discussion  of  the  aircraft1 s  computer.  This 
would  be  included  in  any  other  Software  Requirements 
Document  generated  internally.  The  distingushing  character- 
istics of  the  aircraft  processor  are  highlighted.  This 
section  should  be  written  with  ths  newly  arrived  personnel 
in  mind  as  a  primary  introduction  into  the  aircraft  computer 
system.  Detailed  descriptions  of  the  computer  are  currently 
available  and  do   not   need  to   be   included   here. 

b.  Input  and  Output   Data    Items 

The  purpose  of  this  section  is  to  describe  the 
interface  between  the  aircraft  processor  and  the  devices 
which  input  and  receive  data  from  the  processor.  Input  and 
output  data  are  decribed  as  Data  Items.  This  is  the  only 
section  of  the  document  which  contains  any  information  about 
the      physical   representation      of   ths      data.  In    follow     on 

sections  of  the  document,  the  Data  Items  and  the  values 
which  they  transmit  are  represented  by  symbolic  names.  Each 
Data    Item  is  described  in  the    following    manner: 
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1.  Each    Data    Item   is   given   a    symbolic   name   which   is    stan- 
dardized throughout  the    document. 

2.  A   prose      description    of      its   meaning   and   its   relation 
to   the  device   which  utilizes   it   is   given. 


po 
assigned   to    it. 

4.  The   format   of    the   data   representation   is  given. 

5.  The  processor  instruction  sequence  which  is  required 
to  manipluate  the  Data  Item  (Read,  Transmit,  Write,  etc) 
is   described. 


c.      Operation  Mode 

Possible  states  of  the  program  are  defined  in 
accordance  with  aircraft  operating  scenarios.  A  precise 
frozen  scenario  for  a  particular  flight  profile  is 
described.  It  is  very  difficult  to  describe  the  state  of 
the  OFP  at  any  given  moment  without  a  precise  definition  of 
what  the  aircraft  is  doing  at  the  moment.  This  concept  will 
be   shown   to   critical    in   describing  meaningful  OFP    tests. 

When  possible,  modes  described  by  available 
documentation  should  be  used.  If  unavailable,  the  modes  are 
described  to  match  frequently  encountered  aircraft  operating 
conditions.  NRL  chose  five  modes  to  describe:  alignment, 
navigation,  navigation  update,  weapon  delivery  and  testing. 
The  OFP  is  able  to  exist  in  more  than  one  mode  at  a  time. 
Exclusionary  sets  are  defined  to  prevent  combination  of 
modes  which  are  nonsense.  The  defintion  of  the  operational 
modes  should  be  done  in  cooperation  of  the  OFP  maintenance 
personnel,  program  simulator  personnel,  system  design 
contractor  and  a  group  of  experienced  fleet  users.  Once  a 
mode  is  defined  and  aggreed  on,  it  is  set  and  cannot  be 
changed  without  agreement  of  the  group  described  above.  The 
definition  on  the  mode  would  then  have  to  be  a  careful 
process. 
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Events  in  aircraft  operation  which  would  cause 
the  system  to  switch  modes  are  also  described  in  this 
section.  An  example  would  be  an  event  which  occurs  in 
flight  causing  the  mode  to  switch  from  navigation  to  a  navi- 
gational update.  This  data  is  represented  in  table  form. 
Conditions  about  the  state  of  the  program  which  are  defined 
as  true  for  a  particular  mode  ara  also  given  in  tabular 
form.  These  conditions  are  key  to  understanding  the  state 
of  the  program  during  a  given  mode. 

d.  Functions 

The  computation  of  Output  Data  Items  is 
described  as  one  of  the  many  functions  that  the  OFP 
performs.  There   are     many     functions     involved    during     an 

executing  OFP.  Relations  between  the  state  of  Input  Data 
Items  and  the  aircraft  operating  modes  are  provided.  These 
relations  allow  the  user  to  determine  what  coditions  of  the 
operating  mods  caused  an  Output  Data  Item  to  be  produced. 
The  operational  modes  selected  in  the  above  section  are 
used.      No  reference    is  made    to  clock    time. 

e.  Timing 

The  timing  requirements  for  each  function  is 
stated   in      this    section.  An  example      would   be      the  timing 

requirements  of  the  updates  for  each  display  to  the  aircrew. 
The  maximum  delay  between  a  request  for  an  Input  Data  Item 
and  the  completion  of  processing  yielding  the  Output  Data 
Item      is  given.  If  understood,        the      system   reaction     to 

exceeding  this  value  should  be  described.  This  section  will 
be  very  difficult  to  complete.  In  some  OFPs,  such  as  A-6, 
the  timing  requirements  between  cycles  is  not  static. 
Bounds  would  have  to  computed  instead  of  finite  values.  The 
accurate  completion  of  this  section,  while  difficult,  would 
be        very        valuable      for        future        maintenance.  Timing 
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considerations  are  poorly  defined  and  difficult  to  deal 
with.  They  are  critically  important  to  the  accurate  opera- 
tion of  the  OFP.  An  ability  to  reference  the  timing  consid- 
erations for  each  OFP  function  could  in  fact  be  the  most 
important  aspect  of  the  Software  Requirements  Document. 

f.  Accuracy 

The  accuracy  requirements  for  the  computation  of 
all  Output  Data  Items  are  given.  This  is  another  difficult 
and  important  part  of  the  document.  The  first  version  of 
the  A-7  Software  Requirements  Documsnt  did  not  have  all  of 
the  data  required  to  complete  this  section.  It  is  a  common 
complaint  of  maintenance  personnel  that  they  do  not  know  the 
accuracy  requirements  of  the  data  produced  during  computa- 
tion by  the  OFP.  Ground  and  air  testing  of  the  OFP  may  find 
that  due  to  the  lack  of  accuracy  information  that  a  function 
delivers  incorrect  Output  Data  Itsms  causing  the  OFP  to 
perform  incorrectly.  An  example  could  as  drastic  as  a 
weapon  missing  a  target  or  the  system  crashing  on  unconfu- 
table  Input   Data   Items. 

g.  Ondesired  Events 

Undesired  events,  such  as  processing  an  incor- 
rect Input  Data  Item,  elicit  certain  behavior  from  the  OFP. 
This  behavior  is  described.  The  entrance  into  an  undesired 
situation  should  be  from  a  standard  aircraft  operational 
mode    as      described    earlier.  Input    of      aircrews    should     be 

sought  to  determine  the  best  response,  or  at  least  most 
commonly  observed  response  to  degraded  OFP  operation.  This 
section  could  quickly  grow  in  size  and  complexity  if  every 
combination  of  device  and  system  failure  is  considered.  A 
bound  is  set  on  this  section  by  considering  failure  of  the 
most  important  functions  of  the  OFP,  determined  from  user 
input   and  the  predefined  modes   of   3FP    operation. 
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h.      Partitioning 

The  allowable  partitions  of  the  OFP  are 
described.  Services  which  are  computed  by  the  OFP  but  are 
not  mandatory  for  aircraft  operation  or  execution  of  the  OFP 
are  described.  Functions  which  may  be  canidates  for  removal 
at  a  future  time  are  identified.  This  is  an  important 
aspect  of  the  document  in  that  the  memory  of  the  flight 
system  is  more  often  than  not.  United.  Incorporation  of 
significant  system  enhancements  may  require  the  dropping  of 
nonrequired  functions.  This  would  give  the  system  engineers 
an   easy   reference  to    functions   not   needed. 

i.      Glossary 

The  glossary  defines  symbol  names  and  acronyms 
of   technical  terms   used   throughout   the   document. 

j.      References 

References  used  to  gather  the  data  contained  in 
the    SRD   and   Aircraft    Technical  Manuals   are   listed. 

k.      Data   Dictionary 

The  standard  terms  used  in  function  and  Data 
Item    description   are   listed    and   defined. 

1.      Index 

The  document  is  indexed  in  the  following  manner: 
By  Data  Item  description.  Mode  description  and  usage  and 
function  Output    Data    Item. 

The  Software  Requirements  Document  is  not  an 
easy  quick  fix  to  a  documentation  problem  that  has  existed 
in  some  OFPs  for  years.  It  would  not  be  cheap  to  implement. 
Perhaps  it  can  be  said  that  it  daes  not  fall  within  the 
scope   of  this      thesis   and  offer   a   sslution      for   the   relative 
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short  term.  Consideration  of  the  expected  lifespan  of  the 
aircraft  and  the  OFP  itself  must  first  be  weighed  prior  to 
expending  funds      for    development      of    such      a    document.  If 

considered  against  the  long  expected  lifespan  of  nearly 
every  OFP,  development  of  a  workable  Software  Requirements 
Document  is  feasible.  Before  recoding  of  the  OFP  could  be 
considered,  a  SRD  would  have  to  ba  written.  Generating  a 
SRD  yields  a  document  which  is  usaful  for  current  mainte- 
nance work  and  would  be  required  for  possible  future  OFP 
rewrites.  The  finished  A- 7  Software  Requirements  Document 
while  extensive,  is  a  workable  document  and  appears  easy  to 
follow  for  someone  familar  with  the  terminology  of  the  soft- 
ware it  covers.  Its  format  has  bsen  expressed  by  mainte- 
nance  personnel    as   suitable    for  any   OFP. 

Generation  of  a  good  document  for  OFPs  which 
currently  lack  one  would  be  costly  in  time  and  money.  In 
the  cases  where  only  a  few  personnel  are  familar  with  the 
entire  OFP,  their  input  into  the  document  would  be  critical. 
It  is  also  obvious  that  these  personnel  could  not  be 
expected  to  be  utilized  full  time  on  the  generation  of  the 
SRD  without  imparing  ongoing  OFP  maintenance.  The  effort  to 
write  the  document  would  have  to  bs  extended  over  a  period 
of   two     to  three   years.  The   author      feels  this    is      not  an 

execessive  period  of  time.  It  oovers  approximately  the 
production   of      two    OFP  updates.  \    training      program   could 

also  be  implemented  around  the  SRD  production  in  which  all 
system  maintenance  personnel  are  involved.  Familarity  with 
the  function  of  the  OFP  would  be  increased  as  the  document 
was    produced.  Ultimately    the   document   should      be   entered, 

stored  and  maintained  on  the  eleotronic  document  storage 
system  selected  in  the  first  step  of  documentation 
improvement. 


71 


3.      Aircraft   Performance   Specification   Document 

The  A-6  personnel  complained  about  the  lack  of  a 
document  which  outlined  the  performance  of  the  aircraft 
itself.  A  document  similar  in  function  to  the  Software 
Requirements  Document  for  the  aircraft  is  needed  in  many 
projects.  The  generation  of  such  a  document  would  not  have 
to   involve   maintenance  personnel.  It   should  be   contracted 

out  to  the  manufacturer  and  produce!  in  a  format  suitable  to 
the  maintenance  personnel.  It  also  would  be  very  useful  as 
a  training  aid  to  help  the  new  engineer  understand  the 
system  which  he  will  soon  work.  If  maintained  properly  it 
would  supply  the  maintenance  personnel  with  an  accurate 
definition  of  the  performance  profiles  of  the  aircraft  which 
directly  affect  the  execution  of  ths  OFP.  A  general  format 
is   proposed. 

a.  General   Description 

A  general  description  of  the  aircraft  and 
detailed  description  of  the  mission  definition  are  contained 
in  the  first  section.  This  section  merely  provides  an 
introduction  to  the  platform  and  a  starting  point  for  under- 
standing the  rest   of   the  system. 

b.  Mission   Profiles 

Mission  profiles  are  defined  next.  They  should, 
as  close  as  possible,  match  the  moie  scenarios  presented  in 
the  SRD.  Norial  values  for  the  various  devices  which  inter- 
face with  the  flight  computer  system  are  contained  in 
tabular  form.  Tables  are  generated  for  each  flight  profile. 
The  flight  profiles  again  will  impact  greatly  on  the  later 
testing  phases  of  revised  DFPs.  To  insure  the  generation  of 
meaningful  test  data,  the  flight  profiles  are  standardized. 
Extreme  conditions  which  are  faced  under  combat  situations 
are    also   represented. 
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c.  Degraded   Operation 

Expected  degradations  to  the  aircraft  perform- 
ance are  outlined  in  this  section.  Battle  damage  to  the 
aircraft  which  does  not  render  the  aircraft  unflyable  are 
given.  The  flight  software  personnel  are  able  to  determine 
the  expected  reduction  in  device  demand  and  input  to  the  OFP 
This  section  should  be  modeled  closely  after  the  Undesired 
Events  chapter  of  the  SRD. 

d.  Operating  Ranges 

Actual  specification  of  the  aircraft  operating 
parameters  are  listed.  Ranges  of  possible  input  and  output 
values  for  the  avionics  which  interfaces  with  the  OFP  are 
given.  The  devices  are  divided  into  aircraft  subsystems 
such  as  navigation,  HARPOON  missile  fire  control  and  the 
like.  This   section     serves   as      a   quick     reference   to     the 

actual  values  of  the  Input  and  Output  Data  Items  used  in  the 
Software   Requirements  Document. 

The  Aircraft  Performancs  Specification  Document 
is  not  nearly  as  important  to  the  programmer  as  it  is  to  the 
system   engineer.  It  may    in     fact   allow   the     programmer   to 

crass   the  boundry      between    programmer   and  engineer.  It   is 

usually  available  in  some  form  from  the  manufacturer  without 
a  great  deal  of  expense  being  involved.  Money  should  not  be 
spent  on  its  development  over  the  Software  Requirements 
Document.  It  is  a  supplement  to  the  SRD  to  be  developed  in 
parallel   or  after  completion  of   the   SRD. 
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VI.     OFP    TESTING    IMPROVEMENTS 

A.       INTRODUCTION 

The  very  large  subject  of  OFP  tasting  is  addressed  next. 
Testing  of  software  is  not  an  exact  science  by  any  means. 
Debate  persists  on  methods  of  performing  tests  to  yield 
meaningful  and  accurate  results.  Complex  software,  such  as 
the  OFPs,  present  even  more  difficult  questions  as  to  the 
best  testing  method.  The  complexity  of  the  OFP  presents  the 
engineer  with  a  software  product  that  is  basically  in  an 
untestable  form.  The  state  of  the  OFP  is  difficult  to 
track.  Because  of  this,  it  is  vary  difficult  to  identify 
what  conditions  triggered  a  particular  test  result.  Since 
the  older  OFPs  are  not  modularized,  code  that  requires  modi- 
fication is  very  difficult  to  isolate.  How  then  can  testing 
be  structured  to  assure  that  meaningful  results  are 
attained?  This      is     an  extremely      important      question     in 

consideration  of  the  OFPs  use  in  high  performance  aircraft. 
The  engineer  who  certifies  an  OFP  ready  for  live  flight  test 
must  feel  confident  in  his  product.  The  complexity  of  the 
code  must  have  been  addressed  during  ground  tests  in  order 
that  operating  conditions  in  the  fleet  will  not  trigger  the 
OFP  into  a  failure.  The  high  reliability  required  of  the 
OFP    must    be  obtained   during    the  test    phase. 

The  testing  portion  of  the  aviation  lifecycle  has  been 
identified  as  requiring  the  most  resources  to  accomplish. 
Massive  support  facilities  are  required  in  the  form  of 
flight  simulators.  A   great      deal   of      support   software     is 

required  to  run  simulations  of  the  3FP.  After  ground  tests, 
the  OFP  is  tested  in  live  flight  tests.  The  live  flight 
tests  consume  a  large  portion  of  money  due  to  maintenance  of 
the    flight   range   facilities    and  aircraft    fuel   requirements. 
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Current  test  practices  in  most  OF?  maintenance  facili- 
ties consist  of  running  all  or  parts  of  the  OFP  on  the 
target  computsr  within  the  confines  of  a  flight  simulator. 
The  simulator  is  usually  written  ia  a  moderately  high  level 
programming  lanuage  such  as  Fortran.  It  is  instrumented  to 
attempt  to  track  the  state  of  the  OFP  during  a  test  run. 
The  simulator  support  facility  is  manned  by  different 
personnel  than  the  actual  OFP  maintenance  team.  The  simu- 
lator personnel  write  the  support  software  that  is  used  by 
the    maintenance    personnel  to  test   tie   OFP. 

B.       WEAPOH    SYSTEM   SUPPORT   FACILITY 

The  simulators  fall  under  tha  Weapon  System  Support 
Facility  (WSSF)  for  each  OFP.  The  WSSF  is  a  total  system  by 
which  OFP  maintenance  is  supported  to  do  testing.  The  WSSF 
serves  three  primary    functions: 

1.  OFP  validation  and  verification.  Does  the  proqram  work 
properly  and  did  changes  affect  the  remainder  of  the 
unchanged  code? 

2.  New  weapon  integration.  Design  of  new  weapon  inter- 
faces with  the  entire   flight   software   system. 

3.  Weapon  system  analysis.  Measurement  of  simulated 
results   of  flight    tests    and   weapon   delivery   scenarios. 

The  WSSF  should  be  structured  in  an  evolving  state  to  be 
constantly   improving     the   support   of      the   OFP.  The   author 

reviewed  the  doctrines  for  the  production  of  support  soft- 
ware for  the  &-7,  A-4,  AV-8  and  F-13  OFP  projects.  All  were 
found  to  be  well  structured  methodologies  which  conform  to 
modern   software   engineering    principles   and  techniques. 

The  subject  of  OFP  testing  can  be  seen  to  be  viewed  from 
two    persectives.  First   the     viewpoint   of      the    maintenance 

personnel  who  need  to  test  the  intsgration  of  revised  code 
into  the  entire  OFP.  The  other  belongs  to  the  personnel 
assigned  to  develop  and  maintain  the  support  facilities. 
The    concept  of    what    constitutes   a   successful   test    may   not  be 
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the  same  for  aach  group.  One  manager  of  a  support  facility 
complained  the  maintenance  personnel  assigned  to  the  OFP 
which  he  supported  viewed  simulator  flight  tasting  as  a 
"stick  and  rudder  affair."  Meaning  that  the  maintenance 
personnel  wera  happy  to  load  the  OFP  into  the  test  facility 
and  execute  the  OFP  in  accordance  to  a  poorly  defined  model 
of  the  OFP  during  flight.  The  test  lacked  a  specific  struc- 
ture. He  felt  this  was  a  misguiied  approach  to  obtain  a 
meaningful   test    of   the  OFP    software. 

The  WSSF  can  be  thought  of  as  residing  between  the  test 
requirements  and  the  target  flight  computer  system.  The 
role  of  the  WSSF  centers  around  the  data  supplied  to  the 
target   flight   computer  system   during    a   test. 

Since  the  focus  of  the  WSSF  is  the  supply  of  data  to  the 
target  flight  computer,  OFP  tests  must  be  designed  so  that 
specific  data  is  supplied  to  achiave  a  specific  test  result 
which  is  repeatable.  The  specific  input  data  can  be  seen  to 
bound  the  test  process.  The  user  and  the  WSSF  should  aggree 
on  the  bounds  of  the  simulation  and  freeze  it  from  frequent 
changes.  Tha  WSSF  personnel  are  able  to  break  the  process 
of  test  procedure  software  genaration  into  manageable 
modules  based  on  the  concrete  definition  of  the  test 
requirements. 

The  test  data  design  is  approached  in  the  following 
manner.  The   component     to     be      tsstad   is      identified      and 

isolated.  What  needs  to  be  tested  to  validate  this  compo- 
nent is  identified.  Once  detarmined,  specific  test 
scenarios  ara  designed  by  the  maintenance  and  WSSF 
personnel. 

The  improvement  of  OFP  testing  will  be  centered  on  the 
tools  and  methodologies  of  the  WSSF.  Development  of  the 
WSSF  is  an  ongoing  process  which  attempts  to  constantly 
increase   its  capability   to    support   the  OFP    test   effort. 
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C.       STAHDABD   PLIGHT    TEST   SCENARIOS 

The  most  important  aspect  of  the  generation  of  WSSF 
software  which  will  support  OFP  testing  in  a  meaningful 
manner,  hinges  on  standardized  flight  scenarios-  The  stan- 
dardization of  the  scenarios  attempts  to  let  the  maintenance 
personnel  identify  a  flight  profile  which  will  exercise  the 
OFP  in  such  a  way  that  realistic  meaningful  test  results  are 
obtained.  A  successful  completion  of  the  test  flight  scen- 
ario would  yield  flight  data  whioh  is  recorded  into  an 
output  file.  The  data  recorded  is  compared  to  the  output 
data  expected  from  this  standard  scenario.  The  output  file 
and   instrumentation    data  are  stored   for   historical   purposes. 

The  author  witnessed  the  execution  of  two  test  flight 
scenarios  run     on  the  A-4      flight   simulator.  Dne   scenario 

called  for  the  aircraft  to  take  off  and  execute  a  climb  to 
5,000  feet.  From  there  it  flew  oyer  a  ground  target.  A 
dive  was  initiated  and  several  turns  were  made  around  the 
target.  All  of  this  was  represented  by  simulation  of  the 
HDD  symbols  on  a  CRT  screen.  The  target  was  represented  by 
a  triangle  which  rotated  on  the  screen  in  accordance  to  the 
movement  of  the  aircraft.  The  symbols  viewed  on  the  screen 
were  generated  from  the  actual  signals  that  the  target 
computer  generated  as  it  executed  the  OFP.  The  HSSF  input 
the  data  which  lead  the  target  computer  to  execute  the  OFP 
as  if  the  aircraft  were  actually  in  flight  performing  the 
scenario   described.  The    WSSF  also    provided      the   interface 

between  the  target  computer  and  the  CRT  which  allowed  the 
HUD      simulation.  Instrumentation      of      the      input      to      the 

aircraft  avionics  from  the  target  computer  is  recorded  by 
the    WSSF   into     an  output  lata   file.  Timing   references   are 

recorded  to  be  able  to  compare  the  input  data  with  the 
output  data.  The  state  of  the  OFP  can  hopefully  be  obtained 
and  reasons  why  specific  output  data  was  generated 
determined. 
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The  methodology  of  freezing  the  test  scenarios  is  crit- 
ical to  the  WSSF  support  software  design  process.  The  WSSF 
personnel  and  the  maintenance  personnel  together  decide  on 
the  scenarios  which  exercise  various  functions  of  the  OFP. 
The  freezing  of  the  scenario  definitions  allow  the  WSSF 
personnel  to  implement  a  design  process  which  is  modular  and 
can    be      automated  to    increase   productivity.  Scenarios  are 

continually  built  which  eventually  enable  the  OFP  to  be 
exercised  in  such  a  way  that  the  tested  OFP  can  leave  the 
software   facility   with  a   very   high  level   of   confidence. 

D.       WSSF    PRODUCTION    TOOLS 

The  increasing  capability  of  tha  WSSF  is  critical  to  the 
reduction  of  the  maintenance  effort  of  the  OFP.  The  produc- 
tion of  WSSF  software  should  be  automated  as  much  as 
feasible  to  help  provide  this  increasing  capability.  The 
WSSF  software  does  not  face  the  storage,  hardware  support 
and  timing  constraints  that  must  be  considered  of  the  OFP 
itself.  The  code  generated  can  comply  with  up  to  date  soft- 
ware engineering  principles  and  use  automation  when 
possible. 

Automation  of  the  generation  of  WSSF  code  also  has 
further   advantages.  The   code     produced   initially      is   more 

likely  to  be  considered  correct.  Routine  repetitive  tasks 
are  eliminated,  thus  increasing  productivity.  The  verifica- 
tion of  the  simulator  code  integrity  is  made  simplier. 
Documentation  of  the  simulator  coda  can  be  made  automatic. 
Analysis  tools  can  be  built  for  the  test  results. 
Portability  can  be  obtained  by  using  standard  automation 
techniques. 

The  following  software  tools,  based  on  the  A-4/AV-8  WSSF 
development  strategy,  are  designed  around  automating  the 
production   of   WSSF    software    and      automating   the   execution  of 
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test  scenarios.  There  are  five  tools  mentioned  which  are 
explained  below.  The  process  starts  with  SREM  and  continues 
with  the  Module  Generator  and  FLECS  to  actually  produce 
module  code.  All  three  tools  work  in  conjunction  to  produce 
the  module  code  for  software  used  in  the  flight  simulator. 
The  module  was  defined  from  the  standardized  flight 
scenarios  covered  earlier.  AVSIM  uses  the  input  data  for  a 
particular  test  scenario  to  execute  the  modules,  required  to 
run  that  test  scenario.  AVDOC  uses  data  from  AVSIM  and  the 
Module  Generator  to  produce  standard  forms  for  documentation 
of  a  test  execution.  The  first  three  tools  mentioned  deal 
with    WSSF   software    module   production.  The    final   two   tools 

deal    with   helping      to  automate  the   test      execution   using  the 
modules   written   by   the  first   three   tools. 

1.      SREM 

SREM,  Software  Requirements  Engineering  Methodology, 
designed  by  TRW,  is  a  tool  which  ties  requirements  to  appli- 
cations. A  Requirement  Statement  Language  (RSL)  is  used  by 
SREM  to  generate  input  into  the  Module  Generator  (MOG) .  A 
module  is  first  defined  by  stating  the  requirements  of  the 
module  in  the  SREM  RSL.  The  module  definition  in  the  RSL  is 
processed  and  the  results  are  input  directly  into  the  Module 
Generator.  SREM  is  written  in  Pascal  and  utilizes  a  rela- 
tional database.  The  database  has  the  advantage  of  being 
able  to  be  used  with  other  applications  other  than  SREM. 
SREM  is  the  first  tool  in  automating  the  production  of  WSSF 
software. 

2„      Module    Generator 

The  Module  Generator  takes  the  output  of  SREM  and 
acts  as  a  FLECS-preprocessor  producing  FLECS  code.  FLECS, 
as  will  be  seen,  actually  produces  the  module  source  code. 
MOG      structures      the      application      of      modular      code.  MOG 


79 


addresses  only  the  module  input  and  output.  A  central 
dictionary  is  used  to  define  module  input  and  output.  MOG 
also  automatically  inserts  code  into  the  module  which  is 
used    by   another   tool   to  trace,    debug    and   time   the    module. 

3.       FLECS 

Fortran  Language  with  Extanded  Control  Structures 
(FLECS)  is  a  tool  which  acts  as  a  Fortran  pre- processor 
generating  Fortran  66  code.  It  has  the  capability  to  be 
extended  to  generate  Fortran  77  control  statements.  It 
takes  FLECS  code  frcm  the  MOG  as  its  input  and  converts  it 
into  valid  Fortran  source  code.  It  is  a  stand  alone  tool 
not  tying  directly  to  the  MOG.  This  is  the  tool  which 
yields  the  portability  of  the  WSSF  code.  Currently  all 
support  facilities  but  one  at  NWC  utilize  Fortran  66.  Code 
generated  by  FLECS  is  tranportable  between  the  facilities. 
FLECS  is  the  last  major  tool  used  in  the  generation  of  WSSF 
software.  The  next  two  tools  deal  with  the  execution  of  a 
test  scenario  using  the  software  produced  by  the  first  three 
tools. 

••   AVSIM 

AVSIM,  Avionics  Simulation,  provides  an  interface 
between  the  avionics  hardware  and  the  WSSF  computer  soft- 
ware. It  controls  the  debug,  trace  and  timing  options  of 
the  WSSF  code  generated  by  the  MOG.  The  tool  is  able  to 
configure  itself  in  accordance  with  the  data  contained  in 
the  input  data  file  for  the  test.  It  is  able  to  turn  on  the 
WSSF  modules  required  to  run  a  test  of  the  OFP  by  analysis 
of  the  test  input  data  file.  AVSIM  runs  the  simulation. 
This  is  an  important  automatic  feature  of  the  test  facility. 
Tests   are  much      easier  to   set   up   and    run.  Once    input  data 

for  a  particular  test  is  standardized,  the  output  data 
expected  by  running  of  the  modules  AVSIM  turns  on  can  be 
standardized  also. 
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5.  AVDOC 

AVDOC,  AVSIM  Documentation,  generates  predefined 
forms  from  the  module  generator  source  files.  These  forms 
include:  status  reports,  symbol  dictionary  listings,  cross 
reference  guides  and  keyword  searches  of  the  modules  turned 
on  by  AVSIM  in  the  execution  of  a  tast  scenario.  It  is  able 
to  tie  directly  with  the  AVSIM  and  30G  tools.  AVDOC  can  be 
thought  of  as  a  book  keeping  program  that  expands  AVSIM 
information  to    produce  predefined   documentation   forms. 

6.  Example 

After  a  standardized  flight  scenario  is  defined  by 
the  OFP  maintenance  and  WSSF  personnel,  it  is  broken  into 
modules.  The  WSSF  personnel  take  each  module  and  define  it 
in  terms  cf  its  requirements  in  the  SREM  Requirements 
Statement   Language.  After  this   is    processed,         the   Module 

Generator  structures  the  input  and  output  of  the  module  in 
FLECS  code.  MOG  also  adds  code  which  is  used  by  the  simula- 
tion tool,  AVSIM,  to  trace,  debug  and  time  the  module.  The 
tool  FLECS  takes  the  output  of  the  MOG  and  produces  valid 
Fortran  source  code  for  that  module.  The  generation  of  the 
module  is  completed.  AVSIM  is  used  to  execute  the  required 
modules  for  a  particular  flight  test  scenario  automatically. 
Which  modules  are  activated  are  based  on  the  input  data  file 
for    the  simulated  flight  test.  Once   the    first    three   tools 

generate  the  module  code,  the  module  may  be  stored  until 
activated  by  AVSIM.  AVSIM  also  executes  the  timing,  debug- 
ging and  trace  code  during  the  test  execution.  AVDOC  is 
activated  when  a  test  is  run  to  produce  standard  forms, 
documenting  the   test    execution. 
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7-      WSSF  Tool  Summary 

These  are  the  primary  tools  used  to  automate  soft- 
ware production  and  use  at  one  WSSF  at  NWC.  This  method- 
ology to  establish  an  increasing  capability  in  WSSF 
development  impressed  the  author  enough  that  it  was  felt 
that  a  similar  approach  should  be  taken  on  all  OFP  test 
facilities.  Exact  tools  used  will  depend  on  the  computer 
resources  available.  The  notion  of  fixed  flight  scenarios 
worked  out  between  the  simulator  and  maintenance  personnel 
should  be  adopted.  Until  the  OFPs  are  structured  properly, 
the  biggest  payoff  in  increasing  the  ability  to  meaningfully 
test    the   OFP  resides    in  the    WSSF   development. 
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VII.     CONCLUSIONS 

A.       CONCLUSIONS 

The  thesis  concludes  with  several  observations  and 
recommendations  concerning  the  devslopment  and  maintenance 
of   future  flight  software  systems. 

1.      Design   It  Right 

Future  OFPs  must  learn  from  the  mistakes  made  during 
the  development  of  nearly  every  current  operational  OFP. 
While  it  is  not  always  necessary  to  design  the  flight  soft- 
ware in  a  high  level  language,  structuring  the  code  into 
modules  is  crtical  to  keeping  maintenance  costs  down.  The 
hardware  system  employed  should  be  designed  with  enough 
memory  and  processor  capability  to  handle  the  first  versions 
of  the  OFP  and  expected  updates  without  severe  loss  of  code 
structure  during  optimization.  Documentation  should  be 
produced  in  accordance  with  current  guidelines.  The  produc- 
tion of  a  well  designed  Software  Requirements  Document  is 
the  minimal  acceptable  docu mentation .  Methods  for  defining 
interfaces  for  code  developed  by  different  sources  need  to 
be      defined.  As      aircraft   computer     systems     become     more 

complex,  single  contractor  developed  OFPs  will  become  rare. 
The  interfaces  will  prevent  integration  nightmares  when  the 
final   product   is  brought  together. 

2«      Develop ment /Maintenance   Environments 

Work  should  continue  on  environments  such  as  FASP. 
New  environments  need  to  be  defined  to  support  software  for 
future      flight    systems.  Navy      flight    software      activities 

should      be   allocated      funds    now      to   begin      development    of      a 
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common  development/maintenance  environment  to  be  used  on  all 
flight  software.  These  general  purpose  environments  would 
be  defined  within  guidelines  that  contractors  must  follow 
during  OFP  development.  When  the  Navy  flight  software 
activities  assume  maintenance  responsibility,  the  change 
will  be  smooth  and  maintenance  easier.  This  recommendation 
will  not  be  cheap  to  implement,  but  if  the  quality  of  future 
flight  software  systems  is  to  remain  high  the  money  should 
be  spent  now. 

3.  Money 

More  funds  should  be  allocated  now  to  improve  the 
maintenance  of  operational  flight  software.  As  this  thesis 
hoped  to  propose,  great  expenditures  on  the  current  flight 
software  need  not  be  made.  When  considered  against  the  cost 
of  a  single  aircraft  it  seems  incredible  that  flight  soft- 
ware activities  must  spend  operating  funds  to  develop  a  very 
badly  needed  Software  Requirements  Document.  The  generation 
of  a  SHD  is  not  expensive  when  the  savings  it  will  generate 
over    the  remainer  of   the  OFP  lifecycle  are  recognized. 

4 .  Education 

Two  recommendations  concerning  education  are  made. 
The  first  centers  around  the  personnel  who  make  decisions  on 
flight   software      contracts    and      fund    allocation.  From   the 

observations  made  by  the  author  during  research  for  this 
thesis,  it  was  felt  that  past  high  level  administrators  of 
flight  software  funds  and  contracts  knew  nothing  about  soft- 
ware at  all.  One  manager  of  an  OFP  maintenance  team  relayed 
the  story  of  a  high  level  administrator  located  well  above 
the  trenches  asking  him  how  much  did  the  flight  software  for 
a  particular     aircraft   weigh.  He   needed      to  know      this   in 

order  to  allocate  funds  concerning  that  software.  When  this 
type      of  knowledge      level  is      faced   from      those   who      control 
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funds  for  software  development  and  maintenance  it  is  easy  to 
see  why  some  of  the  errors  made  in  the  past  were  committed. 
Personnel  who  understand  the  nature  of  real  time  embedded 
software  and  the  general  principles  of  software  engineering 
should   be   placed   in    mere   responsible    positions. 

The  second  aspect  of  education  revolves  around 
training  new  engineers  for  employment  in  the  flight  software 
laboratory.  No  facilities  exist  for  training  an  engineer  on 
a  system  such  as  A-6  or  F-14.  The  Navy  should  begin  a 
program  where  engineers  are  identified  in  the  academic 
institutions,  sponsored  and  trained  in  engineering  and 
computer  courses  which  would  most  help  in  working  on  flight 
computer  systems.  This  person  would  then  obligate  to  work 
for    the   Navy  for  a    minimum   length  of    time. 

B.       FIH&L   CONCLUSIONS 

All  cf  the  recommendations  made  in  this  thesis  present 
difficult  decisions  concerning  expenditures  of  funds  for 
aviation   flight    software   maintenance.  There  are   those   who 

feel  that  the  expenditure  of  these  funds  are  not  needed. 
The  fact  remains  that  if  the  high  quality  of  Naval  flight 
software  is  to  continue,  these  difficult  decisions  must  be 
made    and  the  loney    spent. 
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